1.1 --- a/das-projekt.tex	Thu Sep 04 10:09:58 2008 +0200
     1.2 +++ b/das-projekt.tex	Thu Sep 04 11:14:39 2008 +0200
     1.3 @@ -18,7 +18,7 @@
     1.4  
     1.5  Ich war nun der vierte Student der am Projekt arbeitete. Einen Monat nach mit kam noch eine weitere Studentin hinzu.
     1.6  
     1.7 -Als der unser spanischer Teampartner im Juni seine Zeit im Projekt beendete, kam ein neuer Student hinzu. Dieser war von MIT in Cambridge. Es lässt sich also sagen, dass unser Projekt stark international geprägt var. Unsere Kommunikation war folglich größtenteils in Englisch.
     1.8 +Als unser spanischer Teampartner, mein Vorgänger, im Juni seine Zeit im Projekt beendete, kam ein neuer Student hinzu. Dieser war von MIT in Cambridge. Es lässt sich also sagen, dass unser Projekt stark international geprägt var. Unsere Kommunikation war folglich größtenteils in Englisch.
     1.9  
    1.10  
    1.11  \section{Zielsetzung}
    1.12 @@ -27,14 +27,14 @@
    1.13  
    1.14  Üblicherweise werden Roboter über Digitale Signalprozessoren (DSPs) gesteuert. Diese erfordern spezielle Fachkenntnisse in der Programmierung und jeder Roboter wird über einen eigenen DSP gesteuert. Mit Hilfe der Cell-Architektur soll eine Alternative geschaffen werden, die es ermöglicht auf einfache Weise Robotersteuerungen zu entwickeln. Als Werkzeuge sollen die Programmiersprache \emph{C} und das Betriebssystem \emph{GNU/Linux} zum Einsatz kommen, da diese vom Cell unterstützt werden und zudem in der Industrie bekannt sind.
    1.15  
    1.16 -Die Echtzeitfähigkeit die bisher für DSPs sprach kann mit dem Cell-Prozessor ebenso erreicht werden. Seine hohe Skalierbarkeit und die geringen Latenzen ermöglichen es dann sogar eine Vielzahl von Robotern, eventuell sogar ganze Fertigungsstraßen, mit nur einem Cell zu steuern.
    1.17 +Die Echtzeitfähigkeit die bisher für DSPs sprach kann mit dem Cell-Prozessor ebenso erreicht werden. Seine hohe Skalierbarkeit und die geringen Latenzen ermöglichen es dann sogar eine Vielzahl von Robotern, eventuell sogar ganze Fertigungsstraßen, mit nur einem Cell-Chip zu steuern.
    1.18  
    1.19  Dass dies realistische Vorstellungen sind, soll nun gezeigt werden, indem ein Showcase mit vier Robotern und einer visuellen Komponente an einem System erstellt wird.
    1.20  
    1.21  
    1.22  \section{Verwendete Technologie}
    1.23  
    1.24 -Unser Entwicklungssystem war ein angepasster IBM \emph{QS21} Cell/B.E. Blade-Server, welcher zwei Cell-Prozessoren mit je einem Gigabyte Arbeitsspeicher beherbergt. An diesem waren vier Lynx6-Roboterarme von Lynxmotion\footnote{Website: http://lynxmotion.com} angeschlossen, und außer dem noch eine \emph{mvBlueFOX} Kamera von \emph{Matrix Vision}\footnote{Website: http://matrix-vision.com}. Als Betriebsystem lief ein auf den Cell portiertes \emph{Fedora\ 7} GNU/Linux.
    1.25 +Unser Entwicklungssystem war ein angepasster IBM \emph{QS21} Cell/B.E. Blade-Server, welcher zwei Cell-Prozessoren mit je einem Gigabyte Arbeitsspeicher beherbergt. An diesem waren vier Lynx6-Roboterarme von Lynxmotion\footnote{Website: http://lynxmotion.com} angeschlossen, und außer dem noch eine \emph{mvBlueFOX} Kamera von \emph{Matrix Vision}\footnote{Website: http://matrix-vision.com}. Als Betriebsystem lief die PowerPC-Version von \emph{Fedora\ 7} GNU/Linux mit einem angepassten Kernel.
    1.26  
    1.27  \begin{figure}[hbt]
    1.28  	\centering
    1.29 @@ -57,7 +57,7 @@
    1.30  	\label{fig:cellbe-chip}
    1.31  \end{figure}
    1.32  
    1.33 -Bei der Cell/B.E. handelt es sich um eine heterogene Multicore-Architektur. Das bedeutet, dass der Prozessor aus mehreren Kernen besteht, die (im Gegensatz zu den x86-Multicores aber) aus verschiedenen Kerntypen bestehen. Der Cell verfügt über einen PowerPC-Kern (PPE/PPU) und acht sogenannten Synergistic Prozessor Elemente (SPE/SPU). Die PPE ist ein vollwertiger 64-bit PowerPC Kern. Er kann in herkömmlicher Weise verwendet werden, so kann darauf zum Beispiel ein Betriebsystem oder eine beliebige Anwendung laufen. Die SPEs dagegen sind für große Rechenleistung optimiert, Datentransfer-Operationen sind eher langsam.
    1.34 +Bei der Cell/B.E. handelt es sich um eine heterogene Multicore-Architektur. Das bedeutet, dass der Prozessor aus mehreren Kernen besteht, die (im Gegensatz zu den x86-Multicores aber) aus verschiedenen Kerntypen bestehen. Der Cell verfügt über einen PowerPC-Kern (PPE/PPU) und acht sogenannten Synergistic Prozessor Elemente (SPE/SPU). Die PPE ist ein vollwertiger 64-bit PowerPC Kern. Er kann in herkömmlicher Weise verwendet werden, so kann darauf zum Beispiel ein Betriebsystem oder eine beliebige Anwendung laufen. Die SPEs dagegen sind für große Rechenleistung optimiert, Datentransfer-Operationen sind bei ihnen eher langsam.
    1.35  
    1.36  \begin{figure}[hbt]
    1.37  	\centering
    1.38 @@ -90,7 +90,7 @@
    1.39  
    1.40  Der Cell ist ein sehr leistungsstarker Prozessor mit einer Maximalleistung von 230 GigaFLOPS\footnote{FLoating point Operations Per Second --- übliches Maß zum Vergleich von Prozessorleistung}.
    1.41  
    1.42 -Er wird momentan vor allem in Sonys \emph{Playstation 3} und IBM Blade-Servern verbaut. Aber auch in Supercomputern, wie dem \emph{IBM Roadrunner}, der am 9. Juni diesen Jahres als erster Rechner ein PetaFLOPS erreicht hat, wird er eingesetzt. Zudem plant die IBM ihn künftig in ihre Mainframes zu integrieren.
    1.43 +Er wird momentan vor allem in Sonys \emph{Playstation 3} und IBM Blade-Servern verbaut. Aber auch in Supercomputern, wie dem \emph{IBM Roadrunner}, der am 9. Juni diesen Jahres als erster Rechner mehr als ein PetaFLOPS erreicht hat, wird er eingesetzt. Zudem plant die IBM ihn künftig in ihre Mainframes zu integrieren.
    1.44  
    1.45  
    1.46  
    1.47 @@ -135,11 +135,11 @@
    1.48  
    1.49  Als ich meine Arbeit antrat waren folgende Dinge bereits vorhanden.
    1.50  \begin{itemize}
    1.51 -	\item Framework das die ganze low-level Kommunikation zwischen den SPEs regelt
    1.52 +	\item Framework das die low-level Kommunikation zwischen den SPEs regelt
    1.53  	\item Scheduler der die einzelnen Programmmodule verwaltet und die Echtzeiteinhaltung kontrolliert
    1.54  	\item Inverse Kinematik für den Roboterarm
    1.55  	\item Programme mit statischen Bewegungsanweisungen für den Roboter
    1.56 -	\item Einfache dynamische Bewegungen anhand von Gesichtserkennung mit OpenCV
    1.57 +	\item Einfache dynamische Bewegungen an Hand von Gesichtserkennung mit OpenCV
    1.58  \end{itemize}
    1.59  
    1.60  Die alten Arbeiten meiner Vorgänger waren abgeschlossen und mein Teampartner, der schon ein halbes Jahr bei IBM war und während dieser Zeit das Framework ausgearbeitet hatte, feilte daran nur noch herum. Somit fand mit mir eine Art Neubeginn statt.

     2.1 --- a/das-unternehmen.tex	Thu Sep 04 10:09:58 2008 +0200
     2.2 +++ b/das-unternehmen.tex	Thu Sep 04 11:14:39 2008 +0200
     2.3 @@ -19,7 +19,7 @@
     2.4  
     2.5  Als die ersten Computer auftauchten war \ibm\ am forderster Front mit dabei und hatte schnell eine dominierende Stellung im Bereich der Mainframes\footnote{Großrechner --- komplexe Computersysteme mit sehr großer Robustheit, Verlässlichkeit und Leistung} inne.
     2.6  
     2.7 -Ab den 80er Jahren wandelte sich der Markt ---Computer waren klein und für Privatpersonen erschwinglich geworden--- und das Unternehmen hatte mit dem \emph{IBM-PC} eine Antwort auf den \emph{Apple II} der sehr erfolgreich war. Ein Jahrzehnt später verlor die \ibm\ dann aber ihre Vorherrschaft auf dem Gebiet der Personal Computer an die Konkurrenz. Im Jahr 2005 verkaufte das Unternehmen seine PC-Sparte dann komplett an den Chinesischen Hersteller \emph{Lenovo}.
     2.8 +Ab den 80er Jahren wandelte sich der Markt ---Computer waren klein und für Privatpersonen erschwinglich geworden--- und das Unternehmen hatte mit dem \emph{IBM-PC} eine Antwort auf den \emph{Apple II} der sehr erfolgreich war. Ein Jahrzehnt später verlor die \ibm\ dann aber ihre Vorherrschaft auf dem Gebiet der Personal Computer an die Konkurrenz. Im Jahr 2005 verkaufte das Unternehmen seine PC-Sparte dann komplett an den chinesischen Hersteller \emph{Lenovo}.
     2.9  
    2.10  Heutzutage liegt die Priorität des Unternehmens stärker auf Dienstleistungen wie Beratung.
    2.11  
    2.12 @@ -89,7 +89,7 @@
    2.13  
    2.14  Die Hardwareentwicklung befasst sich unter anderem mit dem \emph{System z}, das der Nachfolger des \emph{S/390} und das Flaggschiff der IBM-Hardware ist. Diese besonders ausfallsicheren Server stellen die unternehmenskritische IT-Infrastruktur vieler großer Unternehmen dar. Das Labor war auch maßgeblich an der Entwicklung des \emph{Cell-Prozessors} beteiligt, der in Kooperation mit Sony und Toshiba realisiert wurde. Mit der weltweiten Verantwortung für die Architektur, das Design und die Implementierung von Linux auf \emph{IBM zSeries} ist das Böblinger Entwicklungszentrum das größte Linux Entwicklungszentrum weltweit.
    2.15  
    2.16 -Bei der Software deckt es drei der fünf IBM-Softwarebereiche ab. Das sind die WebSphere, Tivoli und Information Management. Weitere Kernkompetenzen der Software-Entwicklung sind Spracherkennungstechnologien sowie Produkte und Lösungen für die Bioinformatik-, Automobil- und Finanzbranche.
    2.17 +Bei der Software deckt es drei der fünf IBM-Softwarebereiche ab. Das sind WebSphere, Tivoli und Information Management. Weitere Kernkompetenzen der Software-Entwicklung sind Spracherkennungstechnologien sowie Produkte und Lösungen für die Bioinformatik-, Automobil- und Finanzbranche.
    2.18  
    2.19  Im Juli 2008 wurde die \emph{IBM Deutschland Entwicklung GmbH} im Rahmen der \emph{One IBM}-Initiative in \emph{IBM Deutschland Research \& Development GmbH} umbenannt.
    2.20  

     3.1 --- a/oeffentlichkeit.tex	Thu Sep 04 10:09:58 2008 +0200
     3.2 +++ b/oeffentlichkeit.tex	Thu Sep 04 11:14:39 2008 +0200
     3.3 @@ -13,7 +13,7 @@
     3.4  \section{Unternehmensinterne Vorführungen}
     3.5  Unsere Roboter riefen auch bei den Mitarbeitern in unserer Umgebung großes Interesse hervor. Selbstverständlich folgten wir dem Wunsch, bei ihrem Abteilungsmeeting eine kurze Einführung in unser Projekt mit anschließender Demonstration des Fußballspiels zu geben.
     3.6  
     3.7 -Ein zweiter Auftritt war der \emph{Take your children to work day}, den \ibm\ regelmäßig veranstaltet. Wir organisierten eine Programm für eine zwanzig-köpfige Gruppe von Jugendlichen, die dann auch sehr interessiert und aktiv teilnahmen.
     3.8 +Ein zweiter Auftritt war beim \emph{Take your children to work day}, den \ibm\ regelmäßig veranstaltet. Wir organisierten eine Programm für eine zwanzig-köpfige Gruppe von Jugendlichen, die sehr interessiert und aktiv teilnahmen.
     3.9  
    3.10  Auch beim Besuch einer Schulklasse wurden wir für einen Programmpunkt eingesetzt.
    3.11  
    3.12 @@ -29,7 +29,7 @@
    3.13  
    3.14  Unsere Fußball-Roboter waren also ein schöner Einstieg für Gespräche: Vom sichtbaren Aufbau, zur Technologie dahinter, zu den Einsatzgebieten der Cell-Technologie für Spielefirmen.
    3.15  
    3.16 -Das Feedback von Seiten der Besucher, als auch Firmen-intern war sehr positiv --- eine Bestätigung unserer Leistung.
    3.17 +Das Feedback von Seiten der Besucher, als auch Firmen-intern, war sehr positiv --- eine Bestätigung unserer Leistung.
    3.18  
    3.19  
    3.20  \section{Medienwirkung}

     4.1 --- a/taetigkeit.tex	Thu Sep 04 10:09:58 2008 +0200
     4.2 +++ b/taetigkeit.tex	Thu Sep 04 11:14:39 2008 +0200
     4.3 @@ -1,6 +1,6 @@
     4.4  \chapter{Meine Tätigkeit}
     4.5  
     4.6 -In den ersten Tagen musste ich zuerst meinen Rechner einrichten. Er war zwar standardmäßig 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.
     4.7 +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.
     4.8  
     4.9  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.
    4.10  
    4.11 @@ -58,7 +58,7 @@
    4.12  \begin{figure}[hbt]
    4.13  	\centering
    4.14  	\includegraphics[width=0.8\textwidth]{pics/svg-named.png}
    4.15 -	\caption[Generierte SVG-Grafik]{Die generierte SVG-Grafik mit Beschriftungen}
    4.16 +	\caption[Generierte SVG-Grafik]{Eine generierte SVG-Grafik mit Beschriftungen}
    4.17  	\label{fig:svg-named}
    4.18  \end{figure}
    4.19  
    4.20 @@ -97,19 +97,19 @@
    4.21  So zumindest die Theorie, denn \dots
    4.22  
    4.23  \paragraph{Die Realität}
    4.24 -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.
    4.25 +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.
    4.26  
    4.27 -Es galt also diesen Unregelmäßigkeiten entsprechend zu begegnen. Sich ändernde Ballwege waren grundsätlich 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 ausgeglichen um die Ballbahn gleichmäßiger zu machen.
    4.28 +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.
    4.29  
    4.30  \paragraph{Zustandslosigkeit}
    4.31 -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 an diesem Zeitpunkt zweckmäßig.
    4.32 +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.
    4.33  
    4.34  \paragraph{Wo ist der Ball?}
    4.35  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.
    4.36  
    4.37  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.
    4.38  
    4.39 -Dieses Problem löste sich ziemlich gut, indem wir deine 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.
    4.40 +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.
    4.41  
    4.42  \paragraph{Eine neue Struktur}
    4.43  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.
    4.44 @@ -123,7 +123,7 @@
    4.45  \section{Die Vision}
    4.46  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.
    4.47  
    4.48 -In jedem Zyklus holte das Vision-Modul zunächst ein Bild von der Kamera. Dieses wurde auf etwa 200x150 Pixel verkleinert um Rechenzeit zu sparen und noch invertiert. Dann wurde mit \emph{Haar-like features} nach einem Ball gesucht. Von den gefundenen Bällen wurden diejenigen aussortiert, die außerhalb der Spielfläche waren. Waren dann noch immer mehr als ein erkannter Ball übrig, wurde derjenige Ball ausgewählt, der ausgehend von der letzten Position am wahrscheinlichsten war. Als Resultat lieferte das Modul die Koordinaten des Balles, oder zeigte, dass kein Ball gefunden wurde.
    4.49 +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.
    4.50  
    4.51  \begin{figure}[hbt]
    4.52  	\centering
    4.53 @@ -133,7 +133,7 @@
    4.54  \end{figure}
    4.55  
    4.56  \paragraph{Heuristik}
    4.57 -Bilderkennung ist nicht deterministisch und so können bei mehreren Durchläufen mit gleichen Eingangsbild unterschiedliche Bälle gefunden werden. Dies führte dazu, dass bei uns manchmal kein Ball gefunden wurde obwohl einer vorhanden war, ebenso wie gefundene Bälle an Stellen, wo keine waren. Insbesondere die Roboterarme wurden von Zeit zu Zeit als Ball erkannt.
    4.58 +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.
    4.59  
    4.60  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.
    4.61  
    4.62 @@ -145,8 +145,4 @@
    4.63  \end{figure}
    4.64  
    4.65  \paragraph{Ergebnis}
    4.66 -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 arbeitete äußerst zuverlässig.
    4.67 -
    4.68 -% FIXME: add picture of facedetect
    4.69 -
    4.70 -
    4.71 +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.

     5.1 --- a/titel.tex	Thu Sep 04 10:09:58 2008 +0200
     5.2 +++ b/titel.tex	Thu Sep 04 11:14:39 2008 +0200
     5.3 @@ -18,10 +18,7 @@
     5.4  	\end{flushright}
     5.5  
     5.6  
     5.7 -	{ \huge IBM Confidential! }\\
     5.8 -	solange nichts anderes feststeht
     5.9 -
    5.10 -	\rule[4.5cm]{0cm}{0cm}
    5.11 +	\rule[6cm]{0cm}{0cm}
    5.12  
    5.13  	\textit{Dies ist der Bericht zu meinem zweiten Praxissemester im Studiengang Wirtschaftsinformatik an der Hochschule Ulm. Ich absolvierte dieses Praktikum in Böblingen bei der \textbf{IBM Deutschland Research \& Development GmbH}.}
    5.14