annotate taetigkeit.tex @ 53:27a4243536d6 default tip

fixed dash-problem
author meillo@marmaro.de
date Thu, 04 Sep 2008 11:39:17 +0200
parents b5cb0aaf2286
children
Ignore whitespace changes - Everywhere: Within whitespace: At end of lines:
rev   line source
0
de3d14ca2b7a inital commit
schnalke@localhost.localdomain
parents:
diff changeset
1 \chapter{Meine Tätigkeit}
de3d14ca2b7a inital commit
schnalke@localhost.localdomain
parents:
diff changeset
2
51
b5cb0aaf2286 some fixes; removed confidential tag
meillo@marmaro.de
parents: 48
diff changeset
3 In den ersten Tagen musste ich zuerst meinen Rechner einrichten. Das Betriebssystem (Red Hat Enterprise Linux 5) war zwar schon installiert, jedoch mussten diverse Programme eingerichtet werden. Des weiteren wird für die Entwicklung für den Cell ein spezielles Software-Development-Kit (SDK) benötigt. Diese besteht aus eine Vielzahl von Teilen deren Setup einige Zeit in Anspruch nahm.
10
98f2974a3cb4 added content about collision control
schnalke@localhost.localdomain
parents: 0
diff changeset
4
98f2974a3cb4 added content about collision control
schnalke@localhost.localdomain
parents: 0
diff changeset
5 Als ich meinen Rechner soweit einsatzbereit hatte, nahm ich mir die umfangreiche Dokumentation zur Entwicklung von Cell-Programmen vor. Mit Hilfe von ihr sollte und wollte ich einen Überblick über die vorliegende Architektur und die Programmierung für sie gewinnen. Es gibt einen Simulator, der einen Cell-Prozessor imitiert und auf einem gewöhnlichen x86-System läuft. Mit diesem habe ich erste Testprogramme geschrieben um ein Gefühl für Cell-Programmierung zu bekommen.
98f2974a3cb4 added content about collision control
schnalke@localhost.localdomain
parents: 0
diff changeset
6
98f2974a3cb4 added content about collision control
schnalke@localhost.localdomain
parents: 0
diff changeset
7 Nachdem ich dann Zugriff auf den bestehenden Code hatte, studierte ich die Arbeiten meinem Vorgänger, bevor ich mich daran machte, das aktuelle Framework zu erforschen.
98f2974a3cb4 added content about collision control
schnalke@localhost.localdomain
parents: 0
diff changeset
8
0
de3d14ca2b7a inital commit
schnalke@localhost.localdomain
parents:
diff changeset
9
de3d14ca2b7a inital commit
schnalke@localhost.localdomain
parents:
diff changeset
10 \section{Kollisionskontrolle}
de3d14ca2b7a inital commit
schnalke@localhost.localdomain
parents:
diff changeset
11
10
98f2974a3cb4 added content about collision control
schnalke@localhost.localdomain
parents: 0
diff changeset
12 Meine erste Aufgabe bestand darin, eine Kollisionskontrolle für die Roboterarme einzubauen. Diese in sich abgeschlossene Aufgabe war für den Anfang gut geeignet. So konnte ich ohne allzuviel Vorwissen haben zu müssen, sanft in das Projekt einsteigen.
98f2974a3cb4 added content about collision control
schnalke@localhost.localdomain
parents: 0
diff changeset
13
98f2974a3cb4 added content about collision control
schnalke@localhost.localdomain
parents: 0
diff changeset
14 Der Algorithmus sollte möglichst allgemein sein und nicht nur mit genau unserer Roboteranordnung funktionieren.
98f2974a3cb4 added content about collision control
schnalke@localhost.localdomain
parents: 0
diff changeset
15
11
4a9a22285369 added new pictures about the robot arm; added content for collision control
schnalke@localhost.localdomain
parents: 10
diff changeset
16 \begin{figure}[hbt] %FIXME: where put this picture?
4a9a22285369 added new pictures about the robot arm; added content for collision control
schnalke@localhost.localdomain
parents: 10
diff changeset
17 \centering
4a9a22285369 added new pictures about the robot arm; added content for collision control
schnalke@localhost.localdomain
parents: 10
diff changeset
18 \includegraphics[width=0.8\textwidth]{pics/lynx6-terminology.png}
35
f7bc5299e59b better figure captions (new command for that)
schnalke@localhost.localdomain
parents: 26
diff changeset
19 \caption[Terminologie des Roboterarms \source{http://lynxmotion.com, bearbeitet}]{Terminologie des Roboterarms}
41
f72c9230d988 put label after includegraphics, for correct numbering; corrected som typos
meillo@marmaro.de
parents: 38
diff changeset
20 \label{fig:robot-terminology}
11
4a9a22285369 added new pictures about the robot arm; added content for collision control
schnalke@localhost.localdomain
parents: 10
diff changeset
21 \end{figure}
4a9a22285369 added new pictures about the robot arm; added content for collision control
schnalke@localhost.localdomain
parents: 10
diff changeset
22
4a9a22285369 added new pictures about the robot arm; added content for collision control
schnalke@localhost.localdomain
parents: 10
diff changeset
23 \paragraph{Das Problem}
10
98f2974a3cb4 added content about collision control
schnalke@localhost.localdomain
parents: 0
diff changeset
24 Kollisionserkennung ist einfach Abstandsberechnung von Objekten. Unsere Objekte sind Roboterarme, die sich als vier aneinander hängende Linien ansehen lassen --- jedenfalls aus Sicht der Kollisionserkennung. Das eigentliche Problem besteht also aus Abstandsberechnungen von Strecken (nicht Geraden) im Raum. Um nicht die komplizierte Berechnung von Streckenabständen durchführen zu müssen, habe ich jede Strecke durch eine Anzahl Punkte auf ihr ersetzt. Somit musste ich nur Punktabstände berechnen, was einfach ist; allerdings in größerer Anzahl.
98f2974a3cb4 added content about collision control
schnalke@localhost.localdomain
parents: 0
diff changeset
25
98f2974a3cb4 added content about collision control
schnalke@localhost.localdomain
parents: 0
diff changeset
26 Ich berechnete die Abstände jedes Kollisionspunktes eines Roboters, mit jedem Kollisionspunkt jedes anderen Roboters.\footnote{Kollisionen innerhalb eines Roboterarms sollten durch die Kinematik abgefangen werden.} Da dabei, vereinfacht, jeder Punkt mit jedem verglichen wird, resultiert daraus eine quadratische Laufzeit: $O(n^{2})$. Für eine größere Anzahl von Robotern, oder mehr Kollisionspunkten pro Strecke, sollten wir also recht schnell viel Zeit brauchen. Diese Vorraussage wurde von den Performance-Messungen meines Teamspartners bestätigt.
98f2974a3cb4 added content about collision control
schnalke@localhost.localdomain
parents: 0
diff changeset
27
44
529211206f10 removed now obsolete comment
meillo@marmaro.de
parents: 41
diff changeset
28 Mit unseren vier Robotern konnte ich 16 Kollisionspunkte pro Knochen einfügen, ohne besonders viel Zeit zu verbrauchen; 32 Punkte waren noch machbar. Ich entschied mich für vier Kollisionspunkt pro Knochen, denn dies führte zu einer voll ausreichenden Genauigkeit, wie Abbildung \ref{fig:kollisionszone} zeigt.
11
4a9a22285369 added new pictures about the robot arm; added content for collision control
schnalke@localhost.localdomain
parents: 10
diff changeset
29
4a9a22285369 added new pictures about the robot arm; added content for collision control
schnalke@localhost.localdomain
parents: 10
diff changeset
30 \begin{figure}[hbt]
4a9a22285369 added new pictures about the robot arm; added content for collision control
schnalke@localhost.localdomain
parents: 10
diff changeset
31 \centering
4a9a22285369 added new pictures about the robot arm; added content for collision control
schnalke@localhost.localdomain
parents: 10
diff changeset
32 \includegraphics[width=0.4\textwidth]{pics/collision-zones.png}
35
f7bc5299e59b better figure captions (new command for that)
schnalke@localhost.localdomain
parents: 26
diff changeset
33 \caption[Kollisionszonen]{Hervorgehobene Kollisionszone bei vier Kollisionspunkt pro Knochen}
41
f72c9230d988 put label after includegraphics, for correct numbering; corrected som typos
meillo@marmaro.de
parents: 38
diff changeset
34 \label{fig:kollisionszone}
11
4a9a22285369 added new pictures about the robot arm; added content for collision control
schnalke@localhost.localdomain
parents: 10
diff changeset
35 \end{figure}
10
98f2974a3cb4 added content about collision control
schnalke@localhost.localdomain
parents: 0
diff changeset
36
98f2974a3cb4 added content about collision control
schnalke@localhost.localdomain
parents: 0
diff changeset
37
11
4a9a22285369 added new pictures about the robot arm; added content for collision control
schnalke@localhost.localdomain
parents: 10
diff changeset
38 \paragraph{Programmablauf}
23
cf891206ae27 added more content to intelligence module; improves some lines
schnalke@localhost.localdomain
parents: 15
diff changeset
39 Als Ausgangsdaten habe ich die Position und Ausrichtung der Roboter in der ``Welt'' und sämtliche Gelenkwinkel. Aus diesen Daten habe ich die Welt-Koordinaten, also Koordinaten bezogen auf das globale Koordinatensystem, aller Gelenke berechnet. Mit den globalen Koordinaten führe ich die Kollisionsberechnung durch, denn diese liegen im gleichen Koordinatensystem und Abstandberechnungen sind somit einfach: $distance = \sqrt{\Delta x^{2} + \Delta y^{2} + \Delta z^{2}}$.
10
98f2974a3cb4 added content about collision control
schnalke@localhost.localdomain
parents: 0
diff changeset
40
98f2974a3cb4 added content about collision control
schnalke@localhost.localdomain
parents: 0
diff changeset
41
12
2685558f3375 added conclusion to CC; added picture and text to SVG-gen
schnalke@localhost.localdomain
parents: 11
diff changeset
42 \paragraph{Ergebnis}
2685558f3375 added conclusion to CC; added picture and text to SVG-gen
schnalke@localhost.localdomain
parents: 11
diff changeset
43 Die Kollisionskontrolle stoppt das Program bevor eine tatsächliche Kollision auftritt. Die Performance der Moduls ist tragbar, könnte aber weiter verbessert werden. Die Optimierungen können in zwei Richtungen erfolgen. Zum Ersten könnten die Berechnungen für den Cell optimiert werden und somit eine deutlich höhere Rechenleistung erreicht werden. Zum Zweiten könnte die Zahl der Abstandberechnungen reduziert werden indem man zuerst schaut, ob ein Arm überhaupt in der Nähe eines anderen ist, bevor einzelne Kollisionspunkte angeschaut werden.
2685558f3375 added conclusion to CC; added picture and text to SVG-gen
schnalke@localhost.localdomain
parents: 11
diff changeset
44
2685558f3375 added conclusion to CC; added picture and text to SVG-gen
schnalke@localhost.localdomain
parents: 11
diff changeset
45
2685558f3375 added conclusion to CC; added picture and text to SVG-gen
schnalke@localhost.localdomain
parents: 11
diff changeset
46
2685558f3375 added conclusion to CC; added picture and text to SVG-gen
schnalke@localhost.localdomain
parents: 11
diff changeset
47
0
de3d14ca2b7a inital commit
schnalke@localhost.localdomain
parents:
diff changeset
48
de3d14ca2b7a inital commit
schnalke@localhost.localdomain
parents:
diff changeset
49 \section{Visualisierung}
de3d14ca2b7a inital commit
schnalke@localhost.localdomain
parents:
diff changeset
50
12
2685558f3375 added conclusion to CC; added picture and text to SVG-gen
schnalke@localhost.localdomain
parents: 11
diff changeset
51 Im Laufe meiner Arbeiten an der Kollisionskontrolle musste ich mir oft ein Bild von den Stellungen der Roboter machen um die berechneten Werte überprüfen zu können. Ich wollte möglichst unabhängig von den realen Robotern im Labor arbeiten, von denen wir zu dieser Zeit sowieso nur zwei hatten. Anfangs habe ich mir die Winkelstellungen oder die Koordinaten der Gelenke ausgeben lassen und dann unseren defekten Testarm entsprechend eingestellt. So konnte ich mir die Situation einigermaßen vorstellen. Alternativ habe ich zu Stift und Papier gegriffen um mir die Situation zu zeichnen. Dies bedeutete jedoch immer wieder den gleichen Aufwand zu betreiben, nur um die Roboterstellungen visuell vor Augen zu haben.
2685558f3375 added conclusion to CC; added picture and text to SVG-gen
schnalke@localhost.localdomain
parents: 11
diff changeset
52
13
0a7e31e112a6 added content to visualization
schnalke@localhost.localdomain
parents: 12
diff changeset
53 \paragraph{Bilderzeugung}
23
cf891206ae27 added more content to intelligence module; improves some lines
schnalke@localhost.localdomain
parents: 15
diff changeset
54 Wiederkehrende Aufgaben soll man automatisieren --- das ist bekannt. Ich wollte mir also automatisch Bilder generieren lassen, um die stupide Arbeit auf den Computer zu übertragen. Als geeignetes Grafikformat erschien mir das \emph{Scalable Vector Graphics}-Format, das eine Textdatei in XML ist. Somit konnte ich einfach line- und circle-Befehle vom Programm in eine Textdatei schreiben lassen. Im Vergleich zu den bisherigen Ausgaben der Gelenk-Koordinaten, war es in erster Linie nur eine andere Schreibweise. SVG-Dateien werden von gängigen Bildbetrachtern und aktuellen Browsern angezeigt.
12
2685558f3375 added conclusion to CC; added picture and text to SVG-gen
schnalke@localhost.localdomain
parents: 11
diff changeset
55
23
cf891206ae27 added more content to intelligence module; improves some lines
schnalke@localhost.localdomain
parents: 15
diff changeset
56 Ich habe die SVG-Generierung als separates Modul implementiert, das bei Bedarf aktiviert werden kann und dann in jedem Programm-Cycle ein Bild der Roboterstellungen zeichnet. Die Darstellung im Bild ist zwei-dimensional, da 3D-Abbilder nur bei beweglicher Kamera sinnvoll nutzbar sind. Ich habe deshalb eine Dreitafelprojektion verwendet, die auch technischen Zeichnungen und Bauplänen bekannt ist.
13
0a7e31e112a6 added content to visualization
schnalke@localhost.localdomain
parents: 12
diff changeset
57
12
2685558f3375 added conclusion to CC; added picture and text to SVG-gen
schnalke@localhost.localdomain
parents: 11
diff changeset
58 \begin{figure}[hbt]
2685558f3375 added conclusion to CC; added picture and text to SVG-gen
schnalke@localhost.localdomain
parents: 11
diff changeset
59 \centering
2685558f3375 added conclusion to CC; added picture and text to SVG-gen
schnalke@localhost.localdomain
parents: 11
diff changeset
60 \includegraphics[width=0.8\textwidth]{pics/svg-named.png}
51
b5cb0aaf2286 some fixes; removed confidential tag
meillo@marmaro.de
parents: 48
diff changeset
61 \caption[Generierte SVG-Grafik]{Eine generierte SVG-Grafik mit Beschriftungen}
41
f72c9230d988 put label after includegraphics, for correct numbering; corrected som typos
meillo@marmaro.de
parents: 38
diff changeset
62 \label{fig:svg-named}
12
2685558f3375 added conclusion to CC; added picture and text to SVG-gen
schnalke@localhost.localdomain
parents: 11
diff changeset
63 \end{figure}
2685558f3375 added conclusion to CC; added picture and text to SVG-gen
schnalke@localhost.localdomain
parents: 11
diff changeset
64
13
0a7e31e112a6 added content to visualization
schnalke@localhost.localdomain
parents: 12
diff changeset
65 \paragraph{Animation}
23
cf891206ae27 added more content to intelligence module; improves some lines
schnalke@localhost.localdomain
parents: 15
diff changeset
66 Wenig später waren dann selbst die Einzelbilder teilweise zu umständlich, so dass der Wunsch nach einer animierten Darstellung des Geschehens aufkam. SVG-Animationen ausgeben zu lassen wäre deutlich komplizierter geworden, und diese können auch nur von wenigen Programmen dargestellt werden. Deshalb habe ich mit der Programmsammlung \emph{ImageMagick} aus dem SVG-Bildern ein animiertes GIF gemacht. Dieses stellte dann auch die Zeitdimension in den Bewegungen dar. Später wurden die GIFs dann durch komprimierte AVI-Filme (mit \emph{MEncoder} erstellt) ersetzt, da diese deutlich weniger Speicher verbrauchen und schneller erzeugt werden konnten.
13
0a7e31e112a6 added content to visualization
schnalke@localhost.localdomain
parents: 12
diff changeset
67
0a7e31e112a6 added content to visualization
schnalke@localhost.localdomain
parents: 12
diff changeset
68 \paragraph{Ergebnis}
23
cf891206ae27 added more content to intelligence module; improves some lines
schnalke@localhost.localdomain
parents: 15
diff changeset
69 Es liegt hier eine Komponente vor, die die Entwicklung des Restsystems deutlich vereinfacht hat. Mit ihr war es möglich, im Büro zu testen --- es mussten nicht die Roboter im Labor bemüht werden. Zudem konnten durch den direkteren Weg, von den Basisdaten zum visuellen Ergebnis, Fehlerquellen eliminiert werden. So war es unter anderem auch hilfreich bei der Suche nach einem Bug in der Kinematik --- der ja erst durch die Unterschiede zwischen SVG-Simulation und realen Roboterbewegungen sichtbar wurde.
13
0a7e31e112a6 added content to visualization
schnalke@localhost.localdomain
parents: 12
diff changeset
70
0a7e31e112a6 added content to visualization
schnalke@localhost.localdomain
parents: 12
diff changeset
71 Es freut mich um so mehr, dass ich bei Fred Brooks ``The Mythical Man-Month'' bestätigt finde, was ich nebenbei herausgefunden habe: Es ist sinnvoll einen Simulator zu haben und diesen parallel mit dem eigentlichen Programm zu entwickeln.
0a7e31e112a6 added content to visualization
schnalke@localhost.localdomain
parents: 12
diff changeset
72
12
2685558f3375 added conclusion to CC; added picture and text to SVG-gen
schnalke@localhost.localdomain
parents: 11
diff changeset
73
0
de3d14ca2b7a inital commit
schnalke@localhost.localdomain
parents:
diff changeset
74
de3d14ca2b7a inital commit
schnalke@localhost.localdomain
parents:
diff changeset
75 \section{Intelligenz-Modul}
de3d14ca2b7a inital commit
schnalke@localhost.localdomain
parents:
diff changeset
76
15
29268e9521a3 added content for logics module
schnalke@localhost.localdomain
parents: 13
diff changeset
77 Nachdem ich meine Arbeiten an den ersten zwei Modulen soweit fertig war, haben wir im Team beschlossen, dass ich mit dem Intelligenz-Modul weiter machen sollte. Der bisherige Code war natürlich nicht ganz fertig und es war auch durchaus so gewollt, dass die einzelnen Programmteile kontinuierlich weiterentwickelt werden. Neue Funktionalitäten im einen Modul zogen neue Anforderungen in einem weiteren nach sich. So wurde der gesammte Code stückweise ausgebaut.
29268e9521a3 added content for logics module
schnalke@localhost.localdomain
parents: 13
diff changeset
78
29268e9521a3 added content for logics module
schnalke@localhost.localdomain
parents: 13
diff changeset
79 Nichts desto trotz begann ich dann hauptsächlich an der Intelligenz, oder Logik, zu entwickeln.
29268e9521a3 added content for logics module
schnalke@localhost.localdomain
parents: 13
diff changeset
80
29268e9521a3 added content for logics module
schnalke@localhost.localdomain
parents: 13
diff changeset
81
29268e9521a3 added content for logics module
schnalke@localhost.localdomain
parents: 13
diff changeset
82 \paragraph{Aufgabe der Intelligenz}
29268e9521a3 added content for logics module
schnalke@localhost.localdomain
parents: 13
diff changeset
83 Das Logik-Modul plant, entscheidet und gibt die resultierenden Befehle. Es beherbergt den ``interessanten'' Programmcode, denn hier steckt eine Künstliche Intelligenz (so simpel sie auch sei).
29268e9521a3 added content for logics module
schnalke@localhost.localdomain
parents: 13
diff changeset
84
23
cf891206ae27 added more content to intelligence module; improves some lines
schnalke@localhost.localdomain
parents: 15
diff changeset
85 In unserem Fall hat die Logik die aktuelle und letzte Ballposition, sowie die Roboterpositionen zur Verfügung. Das Modul soll ausgeben was welcher Roboterarm als nächstes tun soll.
15
29268e9521a3 added content for logics module
schnalke@localhost.localdomain
parents: 13
diff changeset
86
29268e9521a3 added content for logics module
schnalke@localhost.localdomain
parents: 13
diff changeset
87
29268e9521a3 added content for logics module
schnalke@localhost.localdomain
parents: 13
diff changeset
88 \paragraph{Grundgedanken}
23
cf891206ae27 added more content to intelligence module; improves some lines
schnalke@localhost.localdomain
parents: 15
diff changeset
89 Unser Showcase ist so aufgebaut, dass es immer mindestens einem Roboter möglich ist, den Ball zu spielen. In den meisten Fällen wird der Ball nur von genau einem Arm erreichbar sein, dann wird dieser ihn spielen. Wenn zwei Roboter nah genug sind, übernimmt der Arm mit der geringeren Entfernung (genannt ``Master'') die Kontrolle und spielt den Ball. Der andere Arm (genannt ``Slave'') fungiert als Unterstützung und bewegt sich relativ zum Master. Dieses Verhalten sollte uns bei unvorgesehenen Änderungen des Ballwegs nützlich sein. Die restlichen Arme fahren in eine Warte-Position. Nur wenn der Ball in der Mitte des Spielfeldes zum stehen kommt, haben mehrere Roboter die Möglichkeit ihn zu erreichen. Es wird dann der nahste Roboter aktiv werden.
15
29268e9521a3 added content for logics module
schnalke@localhost.localdomain
parents: 13
diff changeset
90
29268e9521a3 added content for logics module
schnalke@localhost.localdomain
parents: 13
diff changeset
91 \paragraph{Die Schussbewegung} % FIXME: die paragraph-zeile weg?
29268e9521a3 added content for logics module
schnalke@localhost.localdomain
parents: 13
diff changeset
92 Der Ball sollte nicht nur am Paddle (= Schläger), den wir am Greifer des Arms befestigt haben, abprallen, sondern es sollte ihm wieder neue Bewegungsenergie mitgegeben werden. Es war also klar, dass die Roboter eine gewissen Schussbewegung ausführen mussten. Desweiteren war es notwendig das Paddle im richtigen Winkel auszurichten, um den Ball in eine bestimmte Richtung spielen zu können. Das Schussziel sollte in im Intelligenz-Modul gesetzt werden können. Damit wäre es dann auch möglich, dass sich nur zwei Roboter hin und her spielen. Solche ``Spielereien'' sollten auf jeden Fall machbar sein, denn diese machen einen Showcase erst interessant und zeigen einen Hauch menschlichen Verhaltens, was bei Robotern eine wichtige Komponente ist.
29268e9521a3 added content for logics module
schnalke@localhost.localdomain
parents: 13
diff changeset
93
29268e9521a3 added content for logics module
schnalke@localhost.localdomain
parents: 13
diff changeset
94 \paragraph{Mögliche Erweiterungen}
29268e9521a3 added content for logics module
schnalke@localhost.localdomain
parents: 13
diff changeset
95 Die Intelligenz bietet Ausbaumöglichkeiten aller Art. Das geht von einer Bibliothek von Entscheidungsmöglichkeiten, über persönliche Verhaltensmuster einzelner Roboter, bis zu Gruppenverhalten, Taktik, oder gar Finten.
29268e9521a3 added content for logics module
schnalke@localhost.localdomain
parents: 13
diff changeset
96
23
cf891206ae27 added more content to intelligence module; improves some lines
schnalke@localhost.localdomain
parents: 15
diff changeset
97 So zumindest die Theorie, denn \dots
cf891206ae27 added more content to intelligence module; improves some lines
schnalke@localhost.localdomain
parents: 15
diff changeset
98
cf891206ae27 added more content to intelligence module; improves some lines
schnalke@localhost.localdomain
parents: 15
diff changeset
99 \paragraph{Die Realität}
51
b5cb0aaf2286 some fixes; removed confidential tag
meillo@marmaro.de
parents: 48
diff changeset
100 Bevor wir den Aufbau für die Roboter hatten, simulierten wir nur eine mögliche Ballbahn und betrachteten das Ergebnis in den erzeugten SVG-Grafiken. Es funktionierte alles ziemlich gut. Als wir das Ballspiel dann in echt sahen war es katastrophal! Wir hatten nicht bedacht, dass sich der reale Ball keineswegs auf geraden Bahnen bewegte. Eine Billard-Kugel hätte das auf einem Marmor-Untergrund vielleicht getan. Unser Schaumstoffball, der noch nicht mal eine ebene Oberfläche hatte, bewegte sich manchmal fast willkürlich. Er änderte seine Bahn, rollte wieder zurück, blieb einfach liegen, wackelte auf der Stelle \dots\ und unsere Intelligenz, die mit einem (idealen) simulierten Ball umgehen konnte, wusste plötzlich nicht mehr wie ihr geschah.
23
cf891206ae27 added more content to intelligence module; improves some lines
schnalke@localhost.localdomain
parents: 15
diff changeset
101
51
b5cb0aaf2286 some fixes; removed confidential tag
meillo@marmaro.de
parents: 48
diff changeset
102 Es galt also diesen Unregelmäßigkeiten entsprechend zu begegnen. Sich ändernde Ballwege waren grundsätzlich kein Problem, da sie schon von Beginn an bedacht waren. Liegen gebliebene Bälle mussten neu angestoßen werden --- auch dies war mit relativ wenig Aufwand machbar. Auf der Stelle wackelnde Bälle waren schon ein größeres Problem, denn einmal sieht es so aus, als ob der Ball nach rechts läuft, in nächsten Zyklus aber als wenn er nach links läuft, und so weiter. Die Roboter wissen also nicht wohin er sich denn nun bewegt. Ich habe dazu nur Ballbewegungen die zweimal in ungefähr die gleiche Richtung gehen, als tatsächliche Ballbewegung gewertet. Eine Bewegung in die entgegengesetzte Richtung im nächsten Zeitschritt, bedeutet Stillstand. So waren die auf der Stelle zitternden Bälle eliminiert. Alle tatsächlichen Ballbewegungen habe ich dann noch gefiltert um die Ballbahn gleichmäßiger zu machen.
23
cf891206ae27 added more content to intelligence module; improves some lines
schnalke@localhost.localdomain
parents: 15
diff changeset
103
cf891206ae27 added more content to intelligence module; improves some lines
schnalke@localhost.localdomain
parents: 15
diff changeset
104 \paragraph{Zustandslosigkeit}
51
b5cb0aaf2286 some fixes; removed confidential tag
meillo@marmaro.de
parents: 48
diff changeset
105 Das große Problem, das sich mit der Zeit herausstellte, war die Zustandslosigkeit des Intelligenz-Moduls. Ich hatte es so aufgebaut, dass jeweils nur anhand des letzten Zeitschrittes (wenn überhaupt) entschieden wird, wie als nächstes agiert werden soll. In der Realität stellte sich aber heraus, dass dies nicht genug war. Es war nötig, Roboter in Zustände zu versetzen und diese über mehrere Zyklen beibehalten zu können. So benötigt es mehrere Zyklen um einen Ball, der hinter einem Roboterarm festgeklemmt ist, wieder in's Spiel zu bringen. Der Roboter muss dazu seinen Arm heben, über den Ball zurück fahren und ihn von hinten anstoßen. Während dieses Vorgangs sollte er nicht unterbrochen werden. Änderungen an der Grundstruktur der Intelligenz waren an diesem Punkt, vor der ersten Messe, zeitlich nicht mehr möglich; so setzte ich auf Variablen, um Zustände zu speichern. Die Lösung war nicht unbedingt schön, aber zu diesem Zeitpunkt zweckmäßig.
23
cf891206ae27 added more content to intelligence module; improves some lines
schnalke@localhost.localdomain
parents: 15
diff changeset
106
cf891206ae27 added more content to intelligence module; improves some lines
schnalke@localhost.localdomain
parents: 15
diff changeset
107 \paragraph{Wo ist der Ball?}
cf891206ae27 added more content to intelligence module; improves some lines
schnalke@localhost.localdomain
parents: 15
diff changeset
108 Die punktuelle Sichtweise der Dinge machten uns auch im Bezug auf die Position des Balles zu schaffen. Das Problem war, dass wir, wenn kein Ball vom Vision-Modul gefunden wurde, nicht sagen konnten, ob der Ball einfach nicht erkannt wurde, er sich gar nicht mehr im Bild befand, oder er unter einem Roboterarm für die Kamera unsichtbar war. Ein Mensch nimmt dieses Problem zuerst gar nicht wahr. Für uns war es aber zentral, denn je nach tatsächlicher Position mussten verschiedene Aktionen ausgeführt werden: Wurde der Ball nur nicht erkannt, dann sollten die Arme abwarten, in der Hoffnung, dass der Ball im nächsten Zyklus wieder erkannt würde. War der Ball vom Tisch, dann sollten die Roboter in die Wartestellung fahren und so verweilen. War der Ball aber unter einem Arm eingeklemmt, dann sollte dieser eine ``Befreiungsbewegung'' ausführen um den Ball wieder in's Spiel zu bringen. Würde er, im letzten Fall, dies nicht tun, dann wäre das Spiel in einer Sackgasse angelangt, denn beim Abwarten, oder Bewegen in die Wartestellung würde der Ball weiterhin unter dem Arm bleiben --- unsichtbar.
cf891206ae27 added more content to intelligence module; improves some lines
schnalke@localhost.localdomain
parents: 15
diff changeset
109
cf891206ae27 added more content to intelligence module; improves some lines
schnalke@localhost.localdomain
parents: 15
diff changeset
110 Eine der wichtigsten Anforderungen an das Programm war jedoch, dass es ohne menschliches Einwirken quasi endlos laufen sollte. Aus Sackgassensituationen wie dieser mussten also auch Wege hinaus führen.
cf891206ae27 added more content to intelligence module; improves some lines
schnalke@localhost.localdomain
parents: 15
diff changeset
111
51
b5cb0aaf2286 some fixes; removed confidential tag
meillo@marmaro.de
parents: 48
diff changeset
112 Dieses Problem löste sich ziemlich gut, indem wir eine wahrscheinliche Ballposition (ausgehend von der bisherigen Bewegung) annahmen, falls er nicht gefunden wurde. Wurde er jedoch über mehrere Zyklen nicht gefunden, sollte zuerst der Roboter der dem Ball wahrscheinlich am nächsten war, eine Befreiungsbewegung ausführen. War der Ball dann immer noch verschwunden, sollten alle Roboter die Bewegung ausführen. Brachte dies den Ball noch immer nicht zum Vorschein, dann war er vermutlich außerhalb des Spielfeldes und die Roboter sollten in ihre Ruhestellung fahren und warten \dots\ bis der Ball wieder auftauchen würde.
15
29268e9521a3 added content for logics module
schnalke@localhost.localdomain
parents: 13
diff changeset
113
48
0cb0ac135c76 new content for logics module
meillo@marmaro.de
parents: 45
diff changeset
114 \paragraph{Eine neue Struktur}
0cb0ac135c76 new content for logics module
meillo@marmaro.de
parents: 45
diff changeset
115 Nach der ersten Messe machte ich mich daran, die Struktur des Intelligenz-Moduls im Bezug auf dessen Zustandslosigkeit zu ändern. Ich führte ein Task-Konzept ein, bei dem einem Roboter eine bestimmte Aufgabe zugewiesen werden kann. Diese erledigt er komplett, bevor er für weitere Aufgaben frei ist. Aufgaben höherer Priorität brechen allerdings jederzeit unwichtigere Jobs ab und treten an deren Stelle.
0cb0ac135c76 new content for logics module
meillo@marmaro.de
parents: 45
diff changeset
116
0cb0ac135c76 new content for logics module
meillo@marmaro.de
parents: 45
diff changeset
117 Auf diese Weise hatte ich die vorher ``zusammengeschusterte'' Funktionialität mit einem soliden Konzept nachgebaut. Die Handhabung ist jetzt deutlich einfacher und das Programm ohne Probleme erweiterbar. Da der neue Code nur sinngemäß dem alten entspricht (und nicht dessen Unregelmäßigkeiten beinhaltet), muss er erst noch optimiert werden um ein gleich gutes oder besseres Verhalten beim Fußballspiel zu erzielen. Leider war dies bisher noch nicht möglich, es sollte aber kein Problem darstellen.
0cb0ac135c76 new content for logics module
meillo@marmaro.de
parents: 45
diff changeset
118
0cb0ac135c76 new content for logics module
meillo@marmaro.de
parents: 45
diff changeset
119 \paragraph{Ergebnis}
0cb0ac135c76 new content for logics module
meillo@marmaro.de
parents: 45
diff changeset
120 Es existiert nun ein ordentliches Intelligenz-Modul, in etwa 500 Zeilen Quelltext, das vier Robotern zum Fußballspiel verhilft. Seine Struktur wurde mit Blick auf zukünftige Erweiterungen entworfen. Es bietet Ansatzpunkte für spieltaktische Raffinessen, auch wenn diese unsere (derzeitige) Hardware leider nicht ermöglicht. Das Modul ist in seinem jetzigen Umfang für seine Aufgabe gut geeignet. Es sollte allerdings noch Zeit in das Feintuning gesteckt werden. Bei Bedarf kann weitere Spiellogik sehr einfach auf die vorliegende Basis aufgesetzt werden.
0cb0ac135c76 new content for logics module
meillo@marmaro.de
parents: 45
diff changeset
121
15
29268e9521a3 added content for logics module
schnalke@localhost.localdomain
parents: 13
diff changeset
122
25
969a0359b72a added pictures and new content about the vision module
schnalke@localhost.localdomain
parents: 23
diff changeset
123 \section{Die Vision}
969a0359b72a added pictures and new content about the vision module
schnalke@localhost.localdomain
parents: 23
diff changeset
124 Für dieses Modul war zwar hauptsächlich meine Kollegin zuständig, jedoch möchte ich der Vollständigkeit halber ein paar Informationen dazu hier anführen.
969a0359b72a added pictures and new content about the vision module
schnalke@localhost.localdomain
parents: 23
diff changeset
125
51
b5cb0aaf2286 some fixes; removed confidential tag
meillo@marmaro.de
parents: 48
diff changeset
126 In jedem Zyklus holt das Vision-Modul zunächst ein Bild von der Kamera. Dieses wird auf etwa 200x150 Pixel verkleinert um Rechenzeit zu sparen und invertiert. Dann wird mit einem \emph{Haar-like}-Filter aus der \emph{OpenCV}-Bibliothek nach einem Ball gesucht. Von den gefundenen Bällen werden diejenigen aussortiert, die außerhalb der Spielfläche sind. Sind dann noch immer mehr als ein erkannter Ball übrig, wird derjenige Ball ausgewählt, der ausgehend von der letzten Position am wahrscheinlichsten ist. Als Resultat liefert das Modul die Koordinaten des Balles, oder zeigt, dass kein Ball gefunden wurde.
25
969a0359b72a added pictures and new content about the vision module
schnalke@localhost.localdomain
parents: 23
diff changeset
127
969a0359b72a added pictures and new content about the vision module
schnalke@localhost.localdomain
parents: 23
diff changeset
128 \begin{figure}[hbt]
969a0359b72a added pictures and new content about the vision module
schnalke@localhost.localdomain
parents: 23
diff changeset
129 \centering
969a0359b72a added pictures and new content about the vision module
schnalke@localhost.localdomain
parents: 23
diff changeset
130 \includegraphics[width=0.5\textwidth]{pics/captured-area.png}
35
f7bc5299e59b better figure captions (new command for that)
schnalke@localhost.localdomain
parents: 26
diff changeset
131 \caption[Blickfeld der Kamera]{Von der Kamera aufgenommener Bereich}
41
f72c9230d988 put label after includegraphics, for correct numbering; corrected som typos
meillo@marmaro.de
parents: 38
diff changeset
132 \label{fig:captured-area}
25
969a0359b72a added pictures and new content about the vision module
schnalke@localhost.localdomain
parents: 23
diff changeset
133 \end{figure}
969a0359b72a added pictures and new content about the vision module
schnalke@localhost.localdomain
parents: 23
diff changeset
134
969a0359b72a added pictures and new content about the vision module
schnalke@localhost.localdomain
parents: 23
diff changeset
135 \paragraph{Heuristik}
51
b5cb0aaf2286 some fixes; removed confidential tag
meillo@marmaro.de
parents: 48
diff changeset
136 Bilderkennung ist nicht deterministisch und so können bei mehreren Durchläufen mit gleichen Eingangsbild unterschiedliche Bälle gefunden werden. Dies führt dazu, dass bei uns manchmal kein Ball gefunden wird obwohl einer vorhanden ist, ebenso wie gefundene Bälle an Stellen, wo keine sind. Insbesondere die Roboterarme werden von Zeit zu Zeit als Ball erkannt.
25
969a0359b72a added pictures and new content about the vision module
schnalke@localhost.localdomain
parents: 23
diff changeset
137
53
27a4243536d6 fixed dash-problem
meillo@marmaro.de
parents: 51
diff changeset
138 Auch sonst lief bei der Bilderkennung nicht alles so, wie wir uns das dachten --- es scheint fast, als gäbe es dafür ganz eigene Regeln. Unsere Trainingsbilder waren allesamt von einem ganz anderen Ball, als wir nacher verwendeten. Das beste Ergebnis lieferte dann ein früher Test mit nur etwa hundert Fotos; mit mehr Fotos wurde das Ergebnis nur schlechter. Die Größe des Balles war (abgesehen von der Helligkeit natürlich) der wichtigste Einflussfaktor auf den Erkennungserfolg. Das Oberflächenmaterial und die "~bemalung wirkten sich kaum aus. Unser Ball hatte am Ende sogar große schwarze Punkte auf weißem Untergrund (in Anlehnung an den ``Europass'', den Ball der EM 2008), ohne dass die Erkennungsrate merklich schlechter wurde.
25
969a0359b72a added pictures and new content about the vision module
schnalke@localhost.localdomain
parents: 23
diff changeset
139
969a0359b72a added pictures and new content about the vision module
schnalke@localhost.localdomain
parents: 23
diff changeset
140 \begin{figure}[hbt]
969a0359b72a added pictures and new content about the vision module
schnalke@localhost.localdomain
parents: 23
diff changeset
141 \centering
969a0359b72a added pictures and new content about the vision module
schnalke@localhost.localdomain
parents: 23
diff changeset
142 \includegraphics[width=0.7\textwidth]{pics/101balls.png}
35
f7bc5299e59b better figure captions (new command for that)
schnalke@localhost.localdomain
parents: 26
diff changeset
143 \caption[Trainingsbilder]{Unsere Trainingsbilder}
41
f72c9230d988 put label after includegraphics, for correct numbering; corrected som typos
meillo@marmaro.de
parents: 38
diff changeset
144 \label{fig:101balls}
25
969a0359b72a added pictures and new content about the vision module
schnalke@localhost.localdomain
parents: 23
diff changeset
145 \end{figure}
969a0359b72a added pictures and new content about the vision module
schnalke@localhost.localdomain
parents: 23
diff changeset
146
969a0359b72a added pictures and new content about the vision module
schnalke@localhost.localdomain
parents: 23
diff changeset
147 \paragraph{Ergebnis}
51
b5cb0aaf2286 some fixes; removed confidential tag
meillo@marmaro.de
parents: 48
diff changeset
148 Alles in allem können wir aber sehr zufrieden mit unserer Ballerkennung sein. Wir haben eine konstante Erfolgsrate von über 90\% und schlechtes Licht oder ein teilweise verdeckter Ball wirken sich wenig aus. Gleichzeitig ist auch die Rate der Fehlerkennungen recht gering. Durch das invertierte Bild und hellem Ball auf dunklem Grund haben wir sowieso fast alle Fehlermöglichkeiten ausgeschlossen. Mit einem matten Untergrund war dann wirklich die letzte Irritationsgefahr gebannt und unser Vision-Modul arbeitet jetzt äußerst zuverlässig.