Mercurial > docs > ps-bericht-ibm

comparison taetigkeit.tex @ 41:f72c9230d988

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
put label after includegraphics, for correct numbering; corrected som typos
author meillo@marmaro.de
date Wed, 02 Jul 2008 10:39:44 +0200
parents c64bd51d3dd6
children 529211206f10
comparison
equal deleted inserted replaced
40:089e7feb937d 41:f72c9230d988
13 13
14 Der Algorithmus sollte möglichst allgemein sein und nicht nur mit genau unserer Roboteranordnung funktionieren. 14 Der Algorithmus sollte möglichst allgemein sein und nicht nur mit genau unserer Roboteranordnung funktionieren.
15 15
16 \begin{figure}[hbt] %FIXME: where put this picture? 16 \begin{figure}[hbt] %FIXME: where put this picture?
17 \centering 17 \centering
18 \label{fig:robot-terminology}
19 \includegraphics[width=0.8\textwidth]{pics/lynx6-terminology.png} 18 \includegraphics[width=0.8\textwidth]{pics/lynx6-terminology.png}
20 \caption[Terminologie des Roboterarms \source{http://lynxmotion.com, bearbeitet}]{Terminologie des Roboterarms} 19 \caption[Terminologie des Roboterarms \source{http://lynxmotion.com, bearbeitet}]{Terminologie des Roboterarms}
20 \label{fig:robot-terminology}
21 \end{figure} 21 \end{figure}
22 22
23 \paragraph{Das Problem} 23 \paragraph{Das Problem}
24 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. 24 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.
25 25
28 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} %FIXME: bildnr stimmt nicht! 28 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} %FIXME: bildnr stimmt nicht!
29 zeigt. 29 zeigt.
30 30
31 \begin{figure}[hbt] 31 \begin{figure}[hbt]
32 \centering 32 \centering
33 \label{fig:kollisionszone}
34 \includegraphics[width=0.4\textwidth]{pics/collision-zones.png} 33 \includegraphics[width=0.4\textwidth]{pics/collision-zones.png}
35 \caption[Kollisionszonen]{Hervorgehobene Kollisionszone bei vier Kollisionspunkt pro Knochen} 34 \caption[Kollisionszonen]{Hervorgehobene Kollisionszone bei vier Kollisionspunkt pro Knochen}
35 \label{fig:kollisionszone}
36 \end{figure} 36 \end{figure}
37 37
38 38
39 \paragraph{Programmablauf} 39 \paragraph{Programmablauf}
40 Als Ausgangsdaten habe ich die Position und Ausrichtung der Roboter in der ``Welt'' und 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}}$. 40 Als Ausgangsdaten habe ich die Position und Ausrichtung der Roboter in der ``Welt'' und 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}}$.
56 56
57 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 eine Dreitafelprojektion verwendet, die auch technischen Zeichnungen und Bauplänen bekannt ist. 57 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 eine Dreitafelprojektion verwendet, die auch technischen Zeichnungen und Bauplänen bekannt ist.
58 58
59 \begin{figure}[hbt] 59 \begin{figure}[hbt]
60 \centering 60 \centering
61 \label{fig:svg-named}
62 \includegraphics[width=0.8\textwidth]{pics/svg-named.png} 61 \includegraphics[width=0.8\textwidth]{pics/svg-named.png}
63 \caption[Generierte SVG-Grafik]{Die generierte SVG-Grafik mit Beschriftungen} 62 \caption[Generierte SVG-Grafik]{Die generierte SVG-Grafik mit Beschriftungen}
63 \label{fig:svg-named}
64 \end{figure} 64 \end{figure}
65 65
66 \paragraph{Animation} 66 \paragraph{Animation}
67 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 (mit \emph{MEncoder} erstellt) ersetzt, da diese deutlich weniger Speicher verbrauchen und schneller erzeugt werden konnten. 67 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 (mit \emph{MEncoder} erstellt) ersetzt, da diese deutlich weniger Speicher verbrauchen und schneller erzeugt werden konnten.
68 68
118 118
119 In jedem Zyklus holte das Vision-Modul zunächst ein Bild von der Kamera. Dieses wurde auf etwa 200x150 Pixel verkleinert um Rechenzeit zu sparen und noch invertiert. Dann wurde mit \emph{Haar-like features} nach einem Ball gesucht. Von den gefundenen Bällen wurden diejenigen aussortiert, die außerhalb der Spielfläche waren. Waren dann noch immer mehr als ein erkannter Ball übrig, wurde derjenige Ball ausgewählt, der ausgehend von der letzten Position am wahrscheinlichsten war. Als Resultat lieferte das Modul die Koordinaten des Balles, oder zeigte, dass kein Ball gefunden wurde. 119 In jedem Zyklus holte das Vision-Modul zunächst ein Bild von der Kamera. Dieses wurde auf etwa 200x150 Pixel verkleinert um Rechenzeit zu sparen und noch invertiert. Dann wurde mit \emph{Haar-like features} nach einem Ball gesucht. Von den gefundenen Bällen wurden diejenigen aussortiert, die außerhalb der Spielfläche waren. Waren dann noch immer mehr als ein erkannter Ball übrig, wurde derjenige Ball ausgewählt, der ausgehend von der letzten Position am wahrscheinlichsten war. Als Resultat lieferte das Modul die Koordinaten des Balles, oder zeigte, dass kein Ball gefunden wurde.
120 120
121 \begin{figure}[hbt] 121 \begin{figure}[hbt]
122 \centering 122 \centering
123 \label{fig:captured-area}
124 \includegraphics[width=0.5\textwidth]{pics/captured-area.png} 123 \includegraphics[width=0.5\textwidth]{pics/captured-area.png}
125 \caption[Blickfeld der Kamera]{Von der Kamera aufgenommener Bereich} 124 \caption[Blickfeld der Kamera]{Von der Kamera aufgenommener Bereich}
125 \label{fig:captured-area}
126 \end{figure} 126 \end{figure}
127 127
128 \paragraph{Heuristik} 128 \paragraph{Heuristik}
129 Bilderkennung ist nicht deterministisch und so können bei mehreren Durchläufen mit gleichen Eingangsbild unterschiedliche Bälle gefunden werden. Dies führte dazu, dass bei uns manchmal kein Ball gefunden wurde obwohl einer vorhanden war, ebenso wie gefundene Bälle an Stellen, wo keine waren. Insbesondere die Roboterarme wurden von Zeit zu Zeit als Ball erkannt. 129 Bilderkennung ist nicht deterministisch und so können bei mehreren Durchläufen mit gleichen Eingangsbild unterschiedliche Bälle gefunden werden. Dies führte dazu, dass bei uns manchmal kein Ball gefunden wurde obwohl einer vorhanden war, ebenso wie gefundene Bälle an Stellen, wo keine waren. Insbesondere die Roboterarme wurden von Zeit zu Zeit als Ball erkannt.
130 130
131 Auch sonst lief bei der Bilderkennung nicht alles so, wie wir uns das dachten --- es scheint fast, als gäbe es dafür ganz eigene Regeln. Unsere Trainingsbilder waren allesamt von einem ganz anderen Ball, als wir nacher verwendeten. Das beste Ergebnis lieferte dann ein früher Test mit nur etwa hundert Fotos; mit mehr Fotos wurde das Ergebnis nur schlechter. Die Größe des Balles war (abgesehen von der Helligkeit natürlich) der wichtigste Einflussfaktor auf den Erkennungserfolg. Das Oberflächenmaterial und die -bemalung wirkten sich kaum aus. Unser Ball hatte am Ende sogar große schwarze Punkte auf weißem Untergrund (in Anlehnung an den ``Europass'', den Ball der EM 2008), ohne dass die Erkennungsrate merklich schlechter wurde. 131 Auch sonst lief bei der Bilderkennung nicht alles so, wie wir uns das dachten --- es scheint fast, als gäbe es dafür ganz eigene Regeln. Unsere Trainingsbilder waren allesamt von einem ganz anderen Ball, als wir nacher verwendeten. Das beste Ergebnis lieferte dann ein früher Test mit nur etwa hundert Fotos; mit mehr Fotos wurde das Ergebnis nur schlechter. Die Größe des Balles war (abgesehen von der Helligkeit natürlich) der wichtigste Einflussfaktor auf den Erkennungserfolg. Das Oberflächenmaterial und die -bemalung wirkten sich kaum aus. Unser Ball hatte am Ende sogar große schwarze Punkte auf weißem Untergrund (in Anlehnung an den ``Europass'', den Ball der EM 2008), ohne dass die Erkennungsrate merklich schlechter wurde.
132 132
133 \begin{figure}[hbt] 133 \begin{figure}[hbt]
134 \centering 134 \centering
135 \label{fig:101balls}
136 \includegraphics[width=0.7\textwidth]{pics/101balls.png} 135 \includegraphics[width=0.7\textwidth]{pics/101balls.png}
137 \caption[Trainingsbilder]{Unsere Trainingsbilder} 136 \caption[Trainingsbilder]{Unsere Trainingsbilder}
137 \label{fig:101balls}
138 \end{figure} 138 \end{figure}
139 139
140 \paragraph{Ergebnis} 140 \paragraph{Ergebnis}
141 Alles in allem können wir aber sehr zufrieden mit unserer Ballerkennung sein. Wir haben eine konstante Erfolgsrate von über 90\% und schlechtes Licht oder ein teilweise verdeckter Ball wirken sich wenig aus. Gleichzeitig ist auch die Rate der Fehlerkennungen recht gering. Durch das invertierte Bild und hellem Ball auf dunklem Grund haben wir sowieso fast alle Fehlermöglichkeiten ausgeschlossen. Mit einem matten Untergrund war dann wirklich die letzte Irritationsgefahr gebannt und unser Vision-Modul arbeitete äußerst zuverlässig. 141 Alles in allem können wir aber sehr zufrieden mit unserer Ballerkennung sein. Wir haben eine konstante Erfolgsrate von über 90\% und schlechtes Licht oder ein teilweise verdeckter Ball wirken sich wenig aus. Gleichzeitig ist auch die Rate der Fehlerkennungen recht gering. Durch das invertierte Bild und hellem Ball auf dunklem Grund haben wir sowieso fast alle Fehlermöglichkeiten ausgeschlossen. Mit einem matten Untergrund war dann wirklich die letzte Irritationsgefahr gebannt und unser Vision-Modul arbeitete äußerst zuverlässig.
142 142
152 152
153 Erfreulich war auch, dass das Material hielt --- die Servos überstanden die hohe Belastungen. 153 Erfreulich war auch, dass das Material hielt --- die Servos überstanden die hohe Belastungen.
154 154
155 \begin{figure}[hbt] 155 \begin{figure}[hbt]
156 \centering 156 \centering
157 \label{fig:showcase-stand}
158 \includegraphics[width=1.0\textwidth]{pics/automatica-showcase-stand.jpg} 157 \includegraphics[width=1.0\textwidth]{pics/automatica-showcase-stand.jpg}
159 \caption[Der Showcase auf der Messe \source{privat}]{Unser Showcase am Stand von Matrix Vision} 158 \caption[Der Showcase auf der Messe \source{privat}]{Unser Showcase am Stand von Matrix Vision}
159 \label{fig:showcase-stand}
160 \end{figure} 160 \end{figure}
161 161
162 \begin{figure}[hbt] 162 \begin{figure}[hbt]
163 \centering 163 \centering
164 \includegraphics[width=0.8\textwidth]{pics/automatica-besucher.jpg} 164 \includegraphics[width=0.8\textwidth]{pics/automatica-besucher.jpg}