next up previous
Nächste Seite: Formulierung der Aufgabenstellung Aufwärts: Einführung Vorherige Seite: Analyse der Problemstellung

Bestimmung der Designkriterien

Die am häufigsten in der Literatur diskutierten Eigenschaften unterschiedlicher Sehsysteme sind die Geschwindigkeit und die Robustheit. So versuchen sich die am RoboCup teilnehmenden Teams, die reine Softwarelösungen verwenden, regelmäßig mit der Frequenz, mit der ihre Systeme Daten für die Steuerung der Roboter liefern, zu übertreffen. Von der höheren Frequenz versprechen sich die Teams direkte Vorteile gegenüber Gegnern mit langsameren Bildverarbeitungen, denn kürzere Intervalle zwischen den Sensorinformationen ermöglichen eine exaktere Steuerung und eine schnellere Reaktion auf das Spielgeschehen. Konnten 1998 noch Teams mit einer äußerst geringen Bildverarbeitungsrate erfolgreich am RoboCup teilnehmen (die RoboRoos wurden mit einer Rate von nur 5 fps[*] zweite [23]), erhalten heute fast alle Teams Daten mit mehr als 25Hz. Es existiert auch eine Implementierung, inzwischen unter der GPL[*] für jedermann frei zugänglich, die Low-Level Vision[*] mit vier Millionen Pixeln pro Sekunde verspricht. CMVision [2] bietet damit, zumindest laut Spezifikation, selbst auf einem Pentium 200 bei einer üblichen Kameraauflösung von 640 mal 480 Pixeln immerhin noch 13 fps.

Damit läßt sich die erste, unabdingbare Anforderung notieren:


\begin{property}(Echtzeitverarbeitung)
Die Bildverarbeitung muß in Echtzeit, soll heißen, mit mindestens 25 fps und
geringer Verzögerung arbeiten.
\end{property}

Die Robustheit des Systems ist im RoboCup von noch grundlegenderer Bedeutung als die Geschwindigkeit. Kann man in anderen Umgebungen Fehler korrigieren oder Messungen einfach wiederholen, bedeuten im Roboter-Fußball Fehler, wie nicht erkannte oder vertauschte eigene Roboter, den unter Umständen längerfristigen Ausfall eines Spielers. Die korrekte Arbeitsweise des Systems muß daher in jeder Situation gewährleistet sein.


\begin{property}(Robustheit)
Das System muß möglichst zuverlässig arbeiten und a...
... machen oder diese selbstständig bemerken und korrigieren
können.
\end{property}

Neben diesen beiden Punkten haben sich auch etliche Autoren der Kalibrierung dieser Systeme gewidmet. Unter Kalibrierung versteht man die Einstellung des Systems inklusive Kamera auf die aktuellen Umgebungsbedingungen. Der genaue Vorgang des Kalibrierens hängt vom jeweiligen System ab. Für gewöhnlich ist eine Anpassung an die Beleuchtungsverhältnisse, Kameraposition oder die verwendeten Marker notwendig. Da vor den Spielen und in der Halbzeit nur wenig Zeit zum Setup ist, gilt es, die Kalibrierung so weit wie möglich mit geeigneten Tools zu unterstützen. Soll das System auch von ``Laien'', die keinen Einblick in die Interna des Systems haben, verwendet werden können, muß sie vereinfacht und völlig automatisiert werden. Das Interface muß von den im System verwendeten Datenstrukturen (Templates, Farbtabellen, oder andere) abstrahieren und dem Benutzer eine ihm nachvollziehbare Prozedur anbieten.

Besitzt das System ein Interface, über das die benötigten Daten über die aktuellen Umgebungsbedingungen von außerhalb eingespeist werden können, so ist die einfache Kalibrierung nicht mehr zwingenderweise eine Eigenschaft der Bilderkennung, sondern eine von unterstützenden Tools bereitgestellte Funktionalität. Es gilt daher, bei der Entwicklung der Bilderkennung geeignete Interfaces zu definieren.


\begin{property}(Kalibrierung)
Das System muß so angelegt sein, daß der Benutzer...
...hierzu benötigten Werkzeuge leicht bereitgestellt
werden können.
\end{property}

Neben diesen ``konventionellen'' Designkriterien darf man aber nicht die eigentlichen Kernpunkte guten Softwaredesigns vergessen: Flexibilität und Modularität. Erst die Einhaltung dieser Designkriterien machen Software für andere benutzbar und in anderen Projekten wiederverwendbar. Im Falle der für den RoboCup entwickelten Systeme wird in das Design oft soviel Domänenwissen gesteckt, daß schon eine Adaptation auf sehr ähnliche Probleme schwer fällt. Die Systeme sind zumeist exakt auf das Steuern der Fußballspieler zugeschnitten. Oftmals sind sie auch noch unnötig stark auf die (Informations-) Bedürfnisse und die Struktur des eigenen Teams angepaßt. Sinnvoller wäre es natürlich, bei der Entwicklung des Systems auch verwandte Fragestellungen im Auge zu behalten.


\begin{property}(Flexibilität) % Problem mit dem Zeilenumbruch\hspace{2mm}Die ...
...ndern
ein größerer Bereich, eine Problemklasse, abgedeckt werden.
\end{property}

Die Modularität ist eine selbstverständliche Anforderung an gutes Design und braucht nicht weiter diskutiert werden.


\begin{property}(Modularität)
Einmal erarbeitete Datenstrukturen, Algorithmen un...
...flächen sollen
möglichst wiederverwendbar und austauschbar sein.
\end{property}

Unter Abwägung dieser Gesichtspunkte ist es die in dieser Arbeit verfolgte Idee, nicht eine spezielle Lösung nur für ein neues Roboter-Fußball-Team zu erarbeiten, sondern einen Rahmen für eine Bibliothek zu definieren und zu implementieren, die Datenstrukturen und Algorithmen zur Programmierung von Sehsystemen in einem abgegrenzten Anwendungsfeld bereitstellt. Damit ließen sich alternative Algorithmen in die globale Struktur einbinden. Die einzelnen Teile müßten sich dann leicht zu einem im RoboCup verwendbaren Sehsystem zusammenfügen lassen.


next up previous
Nächste Seite: Formulierung der Aufgabenstellung Aufwärts: Einführung Vorherige Seite: Analyse der Problemstellung

2001-12-05