docs/ps-bericht-ibm

diff taetigkeit.tex @ 13:0a7e31e112a6

added content to visualization
author schnalke@localhost.localdomain
date Tue, 13 May 2008 13:59:42 +0200
parents 2685558f3375
children 29268e9521a3
line diff
     1.1 --- a/taetigkeit.tex	Tue May 13 12:06:13 2008 +0200
     1.2 +++ b/taetigkeit.tex	Tue May 13 13:59:42 2008 +0200
     1.3 @@ -50,8 +50,11 @@
     1.4  
     1.5  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.
     1.6  
     1.7 +\paragraph{Bilderzeugung}
     1.8  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.
     1.9  
    1.10 +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 die Dreitafelprojektion verwendet, die auch technischen Zeichnungen und Bauplänen bekannt ist.
    1.11 +
    1.12  \begin{figure}[hbt]
    1.13  	\centering
    1.14  	\label{fig:svg-named}
    1.15 @@ -59,6 +62,14 @@
    1.16  	\caption{Die generierte SVG-Grafik mit Beschriftungen}
    1.17  \end{figure}
    1.18  
    1.19 +\paragraph{Animation}
    1.20 +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 ersetzt, da diese deutlich weniger Speicher verbrauchen und schneller erzeugt werden konnten.
    1.21 +
    1.22 +\paragraph{Ergebnis}
    1.23 +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.
    1.24 +
    1.25 +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.
    1.26 +
    1.27  
    1.28  
    1.29  \section{Intelligenz-Modul}