schnalke@0: \chapter{Meine Tätigkeit}
schnalke@0: 
schnalke@10: 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.
schnalke@10: 
schnalke@10: 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.
schnalke@10: 
schnalke@10: 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.
schnalke@10: 
schnalke@0: 
schnalke@0: \section{Kollisionskontrolle}
schnalke@0: 
schnalke@10: 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.
schnalke@10: 
schnalke@10: Der Algorithmus sollte möglichst allgemein sein und nicht nur mit genau unserer Roboteranordnung funktionieren.
schnalke@10: 
schnalke@11: \begin{figure}[hbt] %FIXME: where put this picture?
schnalke@11: 	\centering
schnalke@11: 	\label{fig:robot-terminology}
schnalke@11: 	\includegraphics[width=0.8\textwidth]{pics/lynx6-terminology.png}
schnalke@11: 	\caption{Terminologie des Roboterarms}
schnalke@11: \end{figure}
schnalke@11: 
schnalke@11: \paragraph{Das Problem}
schnalke@10: 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.
schnalke@10: 
schnalke@10: 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.
schnalke@10: 
schnalke@11: 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.
schnalke@10: 
schnalke@11: \begin{figure}[hbt]
schnalke@11: 	\centering
schnalke@11: 	\label{fig:kollisionszone}
schnalke@11: 	\includegraphics[width=0.4\textwidth]{pics/collision-zones.png}
schnalke@11: 	\caption{Hervorgehobene Kollisionszone bei vier Kollisionspunkt pro Knochen}
schnalke@11: \end{figure}
schnalke@10: 
schnalke@10: 
schnalke@11: \paragraph{Programmablauf}
schnalke@11: Als Ausgangsdaten habe ich die Positionen und Ausrichtungen der Roboter in der ``Welt'' und die 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}}$.
schnalke@11: 
schnalke@10: 
schnalke@12: \paragraph{Ergebnis}
schnalke@12: 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.
schnalke@12: 
schnalke@12: 
schnalke@12: 
schnalke@12: 
schnalke@0: 
schnalke@0: \section{Visualisierung}
schnalke@0: 
schnalke@12: 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.
schnalke@12: 
schnalke@12: 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 in der Welt, war in erster Linie nur eine andere Schreibweise. SVG-Dateien werden von gängigen Bildbetrachtern und aktuellen Browsern angezeigt.
schnalke@12: 
schnalke@12: \begin{figure}[hbt]
schnalke@12: 	\centering
schnalke@12: 	\label{fig:svg-named}
schnalke@12: 	\includegraphics[width=0.8\textwidth]{pics/svg-named.png}
schnalke@12: 	\caption{Die generierte SVG-Grafik mit Beschriftungen}
schnalke@12: \end{figure}
schnalke@12: 
schnalke@12: 
schnalke@0: 
schnalke@0: \section{Intelligenz-Modul}
schnalke@0: 
schnalke@0: 
schnalke@0: 
schnalke@10: 
schnalke@10: 
schnalke@10: \chapter{Teamwork}
schnalke@10: % FIXME: rethink this chapter
schnalke@10: 
schnalke@10: Innerhalb unseres Teams hatte jeder ein Fachgebiet, für das er sich zuständig fühlte. Jedoch arbeiteten wir natürlich gemeinsam am Ganzen und in einer so kleinen Gruppe ist es normal, dass jeder an beliebiger Stelle anpackt wenn es erforderlich ist. Dennoch formierte es sich so, dass mein Teampartner hauptsächlich für das (sein) Framework und Installationen aller Art verantworklich war, zudem hatte er als der mit der meisten Erfahrung die Rolle des Projektleiters inne. Unsere Mitarbeiterin, die einen Monat nach mir dazu stieß, kümmerte sich um die visuelle Thematik. Ich übernahm den Teil der eigentlichen Anwendungsprogrammierung. Das heißt, dass ich die Arbeit der Anderen als Basis nahm um darauf die Anwendungsteile zu konstruieren, die spezifisch für unseren Showcase waren.