| rev |
line source |
|
schnalke@0
|
1 \chapter{Das Projekt}
|
|
schnalke@0
|
2
|
|
schnalke@0
|
3 Das Projekt an dem ich gearbeitet habe, trägt die Bezeichnung ``Real Time Showcase mit dem Cell/B.E. Mikroprozessor: Implementierung einer optisch gesteuerten Produktionseinheit''.
|
|
schnalke@0
|
4
|
|
schnalke@0
|
5 Es war eines der \emph{IBM Speedteams} in diesem Jahr. Die offizielle Beschreibung dafür lautete folgendermaßen:
|
|
schnalke@0
|
6 \begin{quotation}
|
|
schnalke@0
|
7 Der revolutionäre Superchip Cell wurde in Kooperation von Sony, Toshiba und IBM für Sonys Playstation 3 entwickelt. Er wird derzeit in der Playstation 3 und dem IBM Blade Server QS21 eingesetzt. Aufgrund seiner herausragenden Architektur eignet sich der Cell Chip in besonderer Art und Weise für Echtzeit-Datenverarbeitung. Ziel dieses Projekts ist es einen Showcase zu implementieren, der die Leistungsfähigkeit des Cell/B.E.s für Echtzeit-Aufgaben unter Beweis stellt. Hierbei werden vier Roboterarme von zwei Kameras gesteuert. Das Speedteam wird die Ablaufsteuerung der Roboterarme implementieren, damit diese gemeinsam eine Aufgabe erledigen können. Die Kameras werden dabei die Roboterarme kontrollieren. Die Ansteuerung der Roboterarme ist bereits vorhanden, so dass sich dieses Projekt voll auf die Cell/B.E. Programmierung, die optische Datenverarbeitung mit OpenCV und die Algorithmen zur Ablaufsteuerung konzentriert. Als Student haben Sie die Möglichkeit - im wahrsten Sinn des Wortes - Ihre Programmierung anzufassen. Sie Programmieren auf dem interessantesten Prozessor der derzeit auf dem Markt ist und zudem gewinnen Sie Einblick in die Echtzeit-Datenverarbeitung.
|
|
schnalke@0
|
8 \end{quotation}
|
|
schnalke@0
|
9
|
|
schnalke@0
|
10
|
|
schnalke@0
|
11 Begonnen wurde das Projekt im April 2007. Seitdem arbeiten Studenten daran.
|
|
schnalke@0
|
12
|
|
schnalke@33
|
13 Der erste Student hatte die Grundlagen gelegt indem er die low-level Kommunikation mit dem Roboter, die Inverse Kinematik\footnote{Berechnung der Gelenkwinkel in Roboterarmen zum Erreichen eines bestimmten Punktes} und ein erstes Framework für die Programmierung des Cell-Prozessors erstellt hat. Zum Einsatz kamen Lynx6-Roboterarme, die im Abschnitt \ref{robotarme} noch genauer beschrieben werden.
|
|
schnalke@0
|
14
|
|
schnalke@0
|
15 Sein Nachfolger arbeitete während seiner Masterarbeit vor allem an den mathematischen Berechnungen der Inversen Kinematik in allgemeiner Form. Seine Arbeit bezieht sich auf einen Industrie Roboter mit sechs Freiheitsgraden, der leider nicht beschafft werden konnte. Somit simulierte er seine Berechnungen nur.
|
|
schnalke@0
|
16
|
|
schnalke@39
|
17 Student Nummer drei, und damit mein Vorgänger und Kollege, verweilte ein ganzes Jahr im Unternehmen, programmierte während seiner Zeit ein umfassendes Framework um die ganzen low-level Angelegenheiten zu abstrahieren. Dies erleichterte die Programmierung ungemein. Zudem band er \emph{OpenCV} zur visuellen Erkennung mit ein.
|
|
schnalke@0
|
18
|
|
schnalke@39
|
19 Ich war nun der vierte Student der am Projekt arbeitete. Einen Monat nach mit kam noch eine weitere Studentin hinzu.
|
|
schnalke@39
|
20
|
|
schnalke@39
|
21 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.
|
|
schnalke@0
|
22
|
|
schnalke@0
|
23
|
|
schnalke@0
|
24 \section{Zielsetzung}
|
|
schnalke@0
|
25
|
|
schnalke@4
|
26 Ziel des Projekts ist es, ein Robotsteuerungs Framework zu erstellen, das auf der Cell/B.E. basiert.
|
|
schnalke@0
|
27
|
|
schnalke@33
|
28 Ü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.
|
|
schnalke@0
|
29
|
|
schnalke@4
|
30 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.
|
|
schnalke@4
|
31
|
|
schnalke@4
|
32 Dass dies realistische Vorstellungen sind, soll nun gezeigt werden, indem ein Showcase mit vier Robotern und einer visuellen Komponente an einem System erstellt wird.
|
|
schnalke@2
|
33
|
|
schnalke@2
|
34
|
|
schnalke@0
|
35 \section{Verwendete Technologie}
|
|
schnalke@0
|
36
|
|
schnalke@33
|
37 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.
|
|
schnalke@4
|
38
|
|
schnalke@4
|
39 \begin{figure}[hbt]
|
|
schnalke@4
|
40 \centering
|
|
schnalke@4
|
41 \includegraphics[width=0.6\textwidth]{pics/qs21.jpg}
|
|
schnalke@35
|
42 \caption[QS21 Blade-Server \source{IBM}]{QS21 Blade-Server mit zwei Cell-Prozessoren}
|
|
meillo@41
|
43 \label{fig:qs21}
|
|
schnalke@4
|
44 \end{figure}
|
|
schnalke@0
|
45
|
|
schnalke@0
|
46
|
|
schnalke@2
|
47 \subsection{Cell-Prozessor}
|
|
schnalke@0
|
48
|
|
schnalke@0
|
49 Ausgeschrieben \emph{Cell Broadband Engine Architecture} genannt, werde ich hier meist die Kurzformen \emph{Cell/B.E.} oder einfach nur \emph{Cell-Prozessor} verwenden.
|
|
schnalke@0
|
50
|
|
schnalke@0
|
51 Dieser Chip wurde, zwischen 2001 und 2005, in einer Kooperation von Sony, Toshiba und IBM entwickelt. Der Hauptteil der Entwicklungsarbeit wurde dabei von \ibm\ übernommen.
|
|
schnalke@0
|
52
|
|
schnalke@2
|
53 \begin{figure}[hbt]
|
|
schnalke@2
|
54 \centering
|
|
schnalke@2
|
55 \includegraphics[width=0.6\textwidth]{pics/cellbe-chip.png}
|
|
schnalke@35
|
56 \caption[Cell/B.E. Chip \source{IBM ``Introduction to the Cell Broadband Engine''}]{Cell/B.E. Chip}
|
|
meillo@41
|
57 \label{fig:cellbe-chip}
|
|
schnalke@2
|
58 \end{figure}
|
|
schnalke@2
|
59
|
|
schnalke@0
|
60 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.
|
|
schnalke@0
|
61
|
|
schnalke@2
|
62 \begin{figure}[hbt]
|
|
schnalke@2
|
63 \centering
|
|
schnalke@2
|
64 \includegraphics[width=0.8\textwidth]{pics/cellbe-structure.png}
|
|
schnalke@35
|
65 \caption[Die Cell Broadband Engine \source{IBM ``Programming Tutorial''}]{Schematischer Aufbau der Cell/B.E.}
|
|
meillo@41
|
66 \label{fig:cellbe-structure}
|
|
schnalke@2
|
67 \end{figure}
|
|
schnalke@2
|
68
|
|
schnalke@4
|
69 \begin{figure}[hbt]
|
|
schnalke@4
|
70 \centering
|
|
schnalke@4
|
71 \includegraphics[width=0.8\textwidth]{pics/cellbe-ppe-spe.png}
|
|
schnalke@35
|
72 \caption[PPE und SPE \source{IBM ``Programming Tutorial''}]{Schematischer Aufbau von PPE und SPE}
|
|
schnalke@4
|
73 \end{figure}
|
|
schnalke@4
|
74
|
|
schnalke@22
|
75 Üblicherweise übernimmt die PPE die Kontrolle und verteilt die Arbeit auf die einzelnen SPEs die dann unabhängig von einander arbeiten. Die Ergebnisse fließen anschließend an die PPE zurück.
|
|
schnalke@0
|
76
|
|
schnalke@22
|
77 Zur Kommunikation zwischen den einzelnen Kernen stehen drei verschiedene Wege zur Verfügung, welche alle über den Element Interconnect Bus (EIB) abgewickelt werden.
|
|
schnalke@0
|
78
|
|
schnalke@2
|
79 \begin{itemize}
|
|
schnalke@2
|
80 \item \textbf{Mailboxen} Sie sind Hardwareimplementierungen von Nachrichtenwarteschlangen. Jede SPE hat drei davon. Nachrichten haben eine feste Größe von 32 Bit.
|
|
schnalke@2
|
81 \item \textbf{Signale} Wie auch Nachrichten umfasst ein Signal ebenfalls 32 Bit, jedoch existieren keine Warteschlangen, so dass pro Signalkanal genau ein definierter Zustand aktiv sein kann. Jede SPE hat zwei Signalkanäle.
|
|
schnalke@2
|
82 \item \textbf{DMA-Transfers} Hierbei wird den SPEs ermöglicht auf den allgemeinen Hauptspeicher zuzugreifen, ebenso kann die PPE so auf den lokalen Speicher einer SPE zugreifen. DMA\footnote{Direct Memory Access}-Transfers können mit bis zu 16 Kilobyte an Daten übertragen werden. Die Transfers werden vom Memory Flow Controller (MFC) der SPE durchgeführt und können somit parallel zu den aktuellen Instruktionen ablaufen.
|
|
schnalke@2
|
83 \end{itemize}
|
|
schnalke@0
|
84
|
|
schnalke@2
|
85 Für DMA-Transfers empfiehlt es sich, die Technik \emph{Double-Buffering} einzusetzen, bei der die nächsten Daten schon geholt werden, während mit den aktuellen noch gerechnet wird. Auf diese Weise kann die SPE nahezu voll ausgelastet werden.
|
|
schnalke@0
|
86
|
|
schnalke@2
|
87 Mailboxen und Signale werden üblicherweise vor allem für die Übertragung von Statusinformatinen verwendet.
|
|
schnalke@0
|
88
|
|
schnalke@0
|
89
|
|
schnalke@0
|
90
|
|
schnalke@2
|
91 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}.
|
|
schnalke@0
|
92
|
|
meillo@41
|
93 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.
|
|
schnalke@2
|
94
|
|
schnalke@2
|
95
|
|
schnalke@2
|
96
|
|
schnalke@4
|
97 \subsection{Roboterarm} \label{robotarme}
|
|
schnalke@2
|
98
|
|
schnalke@2
|
99 Die von uns verwendeten Roboterarme sind das Modell \emph{Lynx6} vom Hersteller Lynxmotion. Die Roboter sind aus Lexan gefertigt und werden als Bausatz geliefert. Sie sind etwa 20 Zentimeter hoch und 40 lang.
|
|
schnalke@2
|
100
|
|
schnalke@2
|
101 \begin{figure}[hbt]
|
|
schnalke@2
|
102 \centering
|
|
schnalke@2
|
103 \includegraphics[width=0.6\textwidth]{pics/lynx6.jpg}
|
|
schnalke@35
|
104 \caption[Lynxmotion Lynx6 Roboterarm \source{http://lynxmotion.com}]{Lynxmotion Lynx6 Roboterarm}
|
|
meillo@41
|
105 \label{fig:lynx6}
|
|
schnalke@2
|
106 \end{figure}
|
|
schnalke@2
|
107
|
|
meillo@41
|
108 Sie haben fünf Freiheitsgrade (Basisdrehung, Schulter, Ellenbogen, Handgelenk, Handdrehung) und damit einen weniger als gängige Industrieroboter oder der menschliche Arm. Die Zahl ``6'' in der Modellbezeichnung rührt von einem sechsten Gelenk her, das jedoch nur der Greifer ist und damit keinen weiteren Freiheitsgrad darstellt.
|
|
schnalke@2
|
109
|
|
schnalke@2
|
110 Die Bewegung der Gelenke wird von Servomotoren\footnote{Motoren die bestimmte Positionen anfahren und halten können. Häufig im Modellbau eingesetzt.} (kurz ``Servos'') übernommen.
|
|
schnalke@2
|
111
|
|
schnalke@2
|
112 Angeschlossen sind die Roboterarme über USB am Cell-Blade und per serieller Schnittstelle am Roboter, dazwischen sitzt ein USB-zu-Seriell-Konverter.
|
|
schnalke@2
|
113
|
|
schnalke@24
|
114 % FIXME: insert picture with terminology, where??
|
|
schnalke@2
|
115
|
|
schnalke@2
|
116
|
|
schnalke@2
|
117 \subsection{Kamera}
|
|
schnalke@2
|
118
|
|
schnalke@2
|
119 Die optische Komponente wurde erst kurz vor meiner Zeit in das Projekt eingeführt. Anfangs wurde noch eine handelsübliche Webcam verwendet. Später wurde diese durch eine professionelle CCD-Kamera der Firma \emph{Matrix Vision} ersetzt. Bei dieser handelt es sich um eine \emph{mvBlueFOX}, die 100 Mal pro Sekunde ein Schwarz-Weiß-Bild mit ein einer Auflösung von 640x480 Pixeln liefert.
|
|
schnalke@2
|
120
|
|
schnalke@2
|
121 \begin{figure}[hbt]
|
|
schnalke@2
|
122 \centering
|
|
schnalke@8
|
123 \includegraphics[width=6cm]{pics/mvbluefox.png}
|
|
schnalke@35
|
124 \caption[Matrix Vision mvBlueFOX Kamera]{Matrix Vision mvBlueFOX}
|
|
meillo@41
|
125 \label{fig:mvbluefox}
|
|
schnalke@2
|
126 \end{figure}
|
|
schnalke@2
|
127
|
|
schnalke@2
|
128 Zur Bilderkennung verwendeten wir die Open Source Bibliothek \emph{OpenCV}, welche auf den Cell portiert und dafür optimiert ist.
|
|
schnalke@2
|
129
|
|
schnalke@2
|
130
|
|
schnalke@8
|
131 % FIXME: Echtzeit-Umgebung?
|
|
schnalke@0
|
132
|
|
schnalke@0
|
133
|
|
schnalke@0
|
134 \section{Ausgangssituation}
|
|
schnalke@0
|
135
|
|
schnalke@2
|
136 Als ich meine Arbeit antrat waren folgende Dinge bereits vorhanden.
|
|
schnalke@2
|
137 \begin{itemize}
|
|
schnalke@2
|
138 \item Framework das die ganze low-level Kommunikation zwischen den SPEs regelt
|
|
schnalke@2
|
139 \item Scheduler der die einzelnen Programmmodule verwaltet und die Echtzeiteinhaltung kontrolliert
|
|
schnalke@2
|
140 \item Inverse Kinematik für den Roboterarm
|
|
schnalke@2
|
141 \item Programme mit statischen Bewegungsanweisungen für den Roboter
|
|
schnalke@2
|
142 \item Einfache dynamische Bewegungen anhand von Gesichtserkennung mit OpenCV
|
|
schnalke@2
|
143 \end{itemize}
|
|
schnalke@0
|
144
|
|
schnalke@8
|
145 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.
|
|
schnalke@0
|
146
|
|
schnalke@0
|
147
|
|
schnalke@8
|
148 \section{Der Showcase}
|
|
schnalke@8
|
149
|
|
schnalke@8
|
150 Die neue Aufgabe war, einen Showcase zu erstellen, der auf der \emph{Automatica}, einer Messe für Automatisierungstechnik in München, vorgeführt werden sollte.
|
|
schnalke@8
|
151
|
|
schnalke@8
|
152 Der Showcase sollte vier Roboterarme beinhalten, die sich einen Ball zuspielen. Der Ball sollte einen definierten Bereich nicht verlassen --- dafür sollten die Roboter sorgen. Die Position des Balles sollte durch Patternerkennung im Kamerabild herausgefunden werden.
|
|
schnalke@8
|
153
|
|
schnalke@8
|
154 %FIXME weg?: Dies alles sollte in Echtzeit berechnet werden können, selbst ohne ein Echtzeitbetriebssystem zur Verfügung zu haben.
|
|
schnalke@8
|
155
|
|
schnalke@24
|
156 \vspace*{2em}
|
|
schnalke@8
|
157
|
|
schnalke@24
|
158 \begin{figure}[hbt]
|
|
schnalke@24
|
159 \centering
|
|
schnalke@24
|
160 \includegraphics[width=0.6\textwidth]{pics/showcase-robots.jpg}
|
|
schnalke@35
|
161 \caption[Fertiger Showcase]{Am Ende sah es so aus}
|
|
meillo@41
|
162 \label{fig:showcase}
|
|
schnalke@24
|
163 \end{figure}
|
