docs/ps-bericht-ibm

changeset 11:4a9a22285369

added new pictures about the robot arm; added content for collision control
author schnalke@localhost.localdomain
date Tue, 13 May 2008 10:18:59 +0200
parents 98f2974a3cb4
children 2685558f3375
files pics/collision-zones.png pics/lynx6-terminology.png taetigkeit.tex
diffstat 3 files changed, 18 insertions(+), 2 deletions(-) [+]
line diff
     1.1 Binary file pics/collision-zones.png has changed
     2.1 Binary file pics/lynx6-terminology.png has changed
     3.1 --- a/taetigkeit.tex	Tue May 13 08:12:51 2008 +0200
     3.2 +++ b/taetigkeit.tex	Tue May 13 10:18:59 2008 +0200
     3.3 @@ -13,15 +13,31 @@
     3.4  
     3.5  Der Algorithmus sollte möglichst allgemein sein und nicht nur mit genau unserer Roboteranordnung funktionieren.
     3.6  
     3.7 +\begin{figure}[hbt] %FIXME: where put this picture?
     3.8 +	\centering
     3.9 +	\label{fig:robot-terminology}
    3.10 +	\includegraphics[width=0.8\textwidth]{pics/lynx6-terminology.png}
    3.11 +	\caption{Terminologie des Roboterarms}
    3.12 +\end{figure}
    3.13 +
    3.14 +\paragraph{Das Problem}
    3.15  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.
    3.16  
    3.17  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.
    3.18  
    3.19 -Mit unseren vier Robotern konnte ich 16 Kollisionspunkte pro Knochen einfügen, ohne besonders viel Zeit zu verbrauchen; 32 Punkte waren gerade 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. %FIXME ref picture.
    3.20 +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.
    3.21  
    3.22 +\begin{figure}[hbt]
    3.23 +	\centering
    3.24 +	\label{fig:kollisionszone}
    3.25 +	\includegraphics[width=0.4\textwidth]{pics/collision-zones.png}
    3.26 +	\caption{Hervorgehobene Kollisionszone bei vier Kollisionspunkt pro Knochen}
    3.27 +\end{figure}
    3.28  
    3.29  
    3.30 -% FIXME: insert schematic picture of robot arm
    3.31 +\paragraph{Programmablauf}
    3.32 +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}}$.
    3.33 +
    3.34  
    3.35  
    3.36  \section{Visualisierung}