docs/ps-bericht-ibm

diff das-projekt.tex @ 2:d7564f4705a9

die verwendete Technologie beschrieben
author schnalke@localhost.localdomain
date Wed, 07 May 2008 16:44:29 +0200
parents de3d14ca2b7a
children 5bb81f96e7db
line diff
     1.1 --- a/das-projekt.tex	Wed May 07 16:42:14 2008 +0200
     1.2 +++ b/das-projekt.tex	Wed May 07 16:44:29 2008 +0200
     1.3 @@ -27,35 +27,120 @@
     1.4  Kombiniert man nun beide Welten, DSP und Standard Computer, erhält man DSP-ähnliche Applikationen unter einem Linux Betriebssystem gekoppelt mit einer enormen Rechenleistung der nächsten Generation.
     1.5  
     1.6  
     1.7 +Im Laufe des Praktikums soll ein Roboter Controller Framework entstehen, welches auf der Cell-
     1.8 +Architektur von IBM basieren soll. Momentan werden in der Industrie Roboter über DSPs
     1.9 +angesteuert, welche nur schwierig programmiert werden können, da spezielle Kenntnisse nötig sind.
    1.10 +Grundgedanke dieses Projektes ist es, dieses Manko durch den Einsatz der SPUs des Cell-
    1.11 +Prozessors aufzuheben. Da die Cell-Architektur die Programmiersprache C und Linux unterstützt,
    1.12 +können so auf einfachem Wege schnell Robotersteuerungen entwickelt werden ohne spezielle DSP
    1.13 +und FPGA Entwicklung zu betreiben. Dies würde den Zeitfaktor neuer Entwicklung dramatisch
    1.14 +senken.
    1.15 +Ein weiterer Aspekt der Cell-Architektur ist die extrem hohe Skalierbarkeit und die äußerst geringe
    1.16 +Latenz dank mehrerer Prozessorelemente auf einem Chip. Da eine SPU das vielfache eines DSPs
    1.17 +leistet und bis zu acht SPUs auf einem Cell-Core Platz finden ist es denkbar komplette
    1.18 +Fertigungsstraßen durch dieses System zu ersetzen.
    1.19 +Kombiniert man nun beide Welten, DSP und Standard Computer, erhält man DSP-ähnliche
    1.20 +Applikationen unter einem Linux Betriebssystem gekoppelt mit einer enormen Rechenleistung der
    1.21 +nächsten Generation.
    1.22 +
    1.23 +
    1.24  \section{Verwendete Technologie}
    1.25  
    1.26 -Unser Entwicklungssystem war ein angepasster \emph{QS21}\footnote{FIXME} % FIXME
    1.27 -Cell/B.E. Blade-Server. An diesem waren vier Lynx6-Roboterarme von Lynxmotion\footnote{http://lynxmotion.com} angeschlossen, und außer dem noch eine \emph{myBlueFOX} Kamera von \emph{Matrix Vision}\footnote{http://matrix-vision.com}. Als Betriebsystem lief ein Fedora 7.
    1.28 +Unser Entwicklungssystem war ein angepasster IBM \emph{QS21}\footnote{beherbergt zwei Cell-Prozessoren mit je einem Gigabyte Arbeitsspeicher} Cell/B.E. Blade-Server. An diesem waren vier Lynx6-Roboterarme von Lynxmotion\footnote{http://lynxmotion.com} angeschlossen, und außer dem noch eine \emph{mvBlueFOX} Kamera von \emph{Matrix Vision}\footnote{http://matrix-vision.com}. Als Betriebsystem lief ein \emph{Fedora 7}\footnote{http://fedoraproject.org}.
    1.29  
    1.30  
    1.31 -\subsection{Der Cell-Prozessor}
    1.32 +\subsection{Cell-Prozessor}
    1.33  
    1.34  Ausgeschrieben \emph{Cell Broadband Engine Architecture} genannt, werde ich hier meist die Kurzformen \emph{Cell/B.E.} oder einfach nur \emph{Cell-Prozessor} verwenden.
    1.35  
    1.36  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.
    1.37  
    1.38 +\begin{figure}[hbt]
    1.39 +	\centering
    1.40 +	\label{fig:cellbe-chip}
    1.41 +	\includegraphics[width=0.6\textwidth]{pics/cellbe-chip.png}
    1.42 +	\caption{Der Cell/B.E. Chip}
    1.43 +\end{figure}
    1.44 +
    1.45  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.46  
    1.47 +\begin{figure}[hbt]
    1.48 +	\centering
    1.49 +	\label{fig:cellbe-structure}
    1.50 +	\includegraphics[width=0.8\textwidth]{pics/cellbe-structure.png}
    1.51 +	\caption{Schematischer Aufbau der Cell/B.E.}
    1.52 +\end{figure}
    1.53 +
    1.54  Ü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 dann an die PPE zurück.
    1.55  
    1.56 +Zur Kommunikation zwischen den einzelnen Kernen stehen drei verschiedene Kommunikationsarten zur Verfügung, welche alle über den Element Interconnect Bus (EIB) abgewickelt werden.
    1.57  
    1.58 +\begin{itemize}
    1.59 +\item \textbf{Mailboxen} Sie sind Hardwareimplementierungen von Nachrichtenwarteschlangen. Jede SPE hat drei davon. Nachrichten haben eine feste Größe von 32 Bit.
    1.60 +\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.
    1.61 +\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.
    1.62 +\end{itemize}
    1.63  
    1.64 +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.
    1.65  
    1.66 +Mailboxen und Signale werden üblicherweise vor allem für die Übertragung von Statusinformatinen verwendet.
    1.67  
    1.68  
    1.69  
    1.70 -\subsection{Die Roboterarme} \label{robotarme}
    1.71 +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.72  
    1.73 +Er wird momentan vor allem in Sonys \emph{Playstation 3} und IBM Blade-Servern verbaut. Aber auch für Supercomputer, wie dem \emph{IBM Roadrunner}, der dieses Jahr noch fertig gestellt werden und zum ersten Mal ein PetaFLOP erreichen soll, wird er eingesetzt. Zudem plant die IBM ihn künftig in ihre Mainframes zu integrieren.
    1.74 +
    1.75 +
    1.76 +
    1.77 +\subsection{Roboterarme} \label{robotarme}
    1.78 +
    1.79 +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.
    1.80 +
    1.81 +\begin{figure}[hbt]
    1.82 +	\centering
    1.83 +	\label{fig:lynx6}
    1.84 +	\includegraphics[width=0.6\textwidth]{pics/lynx6.jpg}
    1.85 +	\caption{Die von uns verwendeten Roboterarme}
    1.86 +\end{figure}
    1.87 +
    1.88 +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 ein Greifer ist und damit keinen weiteren Freiheitsgrad darstellt.
    1.89 +
    1.90 +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.
    1.91 +
    1.92 +Angeschlossen sind die Roboterarme über USB am Cell-Blade und per serieller Schnittstelle am Roboter, dazwischen sitzt ein USB-zu-Seriell-Konverter.
    1.93 +
    1.94 +
    1.95 +
    1.96 +\subsection{Kamera}
    1.97 +
    1.98 +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.
    1.99 +
   1.100 +\begin{figure}[hbt]
   1.101 +	\centering
   1.102 +	\label{fig:mvbluefox}
   1.103 +	\includegraphics[width=6cm]{pics/mvbluefox.jpg}
   1.104 +	\caption{Unsere Kamera}
   1.105 +\end{figure}
   1.106 +
   1.107 +Zur Bilderkennung verwendeten wir die Open Source Bibliothek \emph{OpenCV}, welche auf den Cell portiert und dafür optimiert ist.
   1.108 +
   1.109 +
   1.110 +% FIXME: Echtzeit-Umgebung
   1.111  
   1.112  
   1.113  \section{Ausgangssituation}
   1.114  
   1.115 +Als ich meine Arbeit antrat waren folgende Dinge bereits vorhanden.
   1.116 +\begin{itemize}
   1.117 +	\item Framework das die ganze low-level Kommunikation zwischen den SPEs regelt
   1.118 +	\item Scheduler der die einzelnen Programmmodule verwaltet und die Echtzeiteinhaltung kontrolliert
   1.119 +	\item Inverse Kinematik für den Roboterarm
   1.120 +	\item Programme mit statischen Bewegungsanweisungen für den Roboter
   1.121 +	\item Einfache dynamische Bewegungen anhand von Gesichtserkennung mit OpenCV
   1.122 +\end{itemize}
   1.123  
   1.124 -\section{Mein Projektteil}
   1.125 +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. Das Ziel war die \emph{Automatica} eine Messe für Automatisierungstechnik in München. Dafür sollte ein neuer Showcase erstellt werden.
   1.126  
   1.127 +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.
   1.128