Anforderungen an eine Entwicklungsumgebung

Vor dem Hintergrund dieser Probleme stellt sich die Frage, wie AR-Anwendungen bislang in der Praxis entwickelt werden.

Die Anwort ist, daß sie auf Desktop-Systemen entwickelt werden. Immer dann, wenn die Anwendung getestet werden muß, kopiert der Entwickler sie auf das mobile Gerät, packt die verwendete Hardware z.B. in einen Rucksack, schnallt diesen auf seinen Rücken, setzt das HMD auf, überprüft die Verkabelung und verläßt das Büro, um die Anwendung in der Praxis zu testen. Während des Testvorgangs kann er eventuelle Fehlfunktionen nur registrieren, aber ihnen nicht auf den Grund gehen, weil es keine Möglichkeit gibt, während der Praxistests die Anwendung zu debuggen. Danach geht der Entwickler wieder in sein Büro und versucht, irgendwie die Ursachen der Fehlfunktionen zu finden und zu beseitigen.

Es ist offensichtlich, daß diese Vorgehensweise extrem ineffektiv ist. Anders als Desktop-Rechner, die im Allgemeinen aus erprobten Standardkomponenten bestehen, die zuverlässig funktionieren, sind die meisten mobilen AR-Geräte Eigenkonstruktionen. Die verwendete Hardware (GPS-Empfänger, Kompasse, Trackingsysteme) ist exotisch und funktioniert häufig nur unzuverlässig. Das gesamte System ist nicht integriert, sondern besteht aus einer Vielzahl von Einzelteilen, die über unzählige Kabel miteinander verbunden sind. Viele dieser Einzelteile benötigen eine eigene Stromversorgung, so daß der Anwender noch eine Vielzahl von Batterien mit sich herumträgt. Wie man sich vorstellen kann, sind Hardwarefehlfunktionen bei einem solchen System an der Tagesordnung – sei es, weil ein Gerät nicht korrekt initialisiert wurde, ein Stecker beim Herumlaufen aus der Buchse gerutscht ist, irgendwelche Wackelkontakte auftreten, oder eine der diversen Batterien leer ist.

Der Entwickler selber ist beim Testen meist nicht in der Lage herauszufinden, warum sein System nicht funktioniert – er kann nur feststellen, daß eine Fehlfunktion auftritt, aber nicht, warum sie auftritt und ob die Ursache dafür in seiner Software zu finden ist oder in einer Fehlfunktion der Hardware. Ein gutes Beispiel dafür ist der GPS-Empfänger. Nehmen wir an, der Entwickler stellt während eines Testlaufs fest, daß seine Software nicht die korrekte Position verwendet. Dafür kann es eine ganze Reihe von Ursachen geben:

• Die Software kann falsch programmiert sein, d.h. das System erhält zwar die korrekten Positionsdaten, aber sie werden von der Anwendung falsch ausgewertet.

Dies ist letztendlich der einzige Fehler, der in der Verantwortung des Entwicklers liegt.

• Der GPS-Empfänger wurde falsch initialisiert. GPS-Empfänger sind eine relativ exotische Hardware und funktionieren daher häufig nicht so zuverläßig wie Standard-PC-Komponenten. Selbst wenn das Initialisierungsprotokoll von der Anwendung korrekt durchgeführt wird, kann es passieren, daß der Empfänger nicht wie gewünscht funktioniert.

• Der GPS-Empfänger funktioniert zwar korrekt, kann aber derzeit die Position nicht bestimmen. GPS-Empfänger benötigen immer Kontakt mit einer ausreichenden Anzahl von Satelliten. Dieser Kontakt kann sehr schnell verloren gehen, z.B. dadurch, daß man sich hinter Gebäude oder sogar einfach nur unter das dichte Blätterwerk einer Baumkrone begibt. Im laufenden Betrieb liefern GPS-Empfänger in einem solchen Fall eine angenäherte Position, aber bei der Initialisierung des Empfängers beim Start der Anwendung funktioniert das nicht. Praktische Erfahrungen haben gezeigt, daß es bis zu 15 Minuten dauern kann, bis GPS-Empfänger die ersten Positionsdaten liefern, wenn sich der Standort seit dem letzten Betrieb des Empfängers stark verändert hat.

• Unter Umständen ist einfach ein Stecker aus seiner Buchse gerutscht, oder es gibt irgendwo einen Wackelkontakt. Als problematisch erweisen sich hier insbesondere die weit verbreiteten USB-Anschlüsse. Auf der einen Seite erleichtern sie das Leben des Entwicklers, weil er über Hubs beliebig viele USB-Geräte an den Rechner anschließen kann und damit die Ausrüstung nicht mehr von der Zahl der am Rechner vorhandenen Schnittstellen limitiert wird. Auf der anderen Seite kann man USB-Stecker aber nicht mehr wie die alten RS232-Stecker an der Buchse festschrauben. Bei mobilen Geräten, wo ständig der gesamte Hardwareaufbau in Bewegung ist, stellt das ein großes Problem dar, welches sich nur durch den großzügigen Einsatz von Klebeband bewältigen läßt.

• Und zu guter Letzt kann auch einfach die Batterie leer sein, die den GPS-Empfänger mit Strom versorgt. Die Versorgung aller Geräte eines mobilen AR-Systems mit Strom stellt eine der größten Herausforderungen dar. Leider beziehen viele Geräte den benötigten Strom nicht über die Verbindung mit dem Rechner, sondern benötigen eigene, externe Stromversorgungen. Selbstverständlich hat hier jedes Gerät seine eigenen Anforderungen an Stromspannung und Stromstärke, sodaß der Anwender üblicherweise eine ganze Reihe von unterschiedlichen Batterien mit sich herumtragen muß, die alle einen unterschiedlichen Ladezustand und unterschiedliche Kapazität haben und daher zu den verschiedensten Zeitpunkten neu geladen werden müssen.

Wenn der Entwickler während des Tests seines AR-Systems also feststellt, daß das System seine Position nicht korrekt berücksichtigt, stellen sich ihm folgende Fragen:

• Liefert der GPS-Empfänger irgendwelche Positionsdaten? Wenn ja, liegt die Ursache für die Fehlfunktion in der Anwendung. Um diese Frage zu beantworten, müßte der Entwickler die Möglichkeit haben, sich vom Gerätemanagement die zuletzt vom GPS-Empfänger erhaltenen Nachrichten anzeigen zu lassen.

• Wenn der GPS-Empfänger keine Positionsdaten liefert, wurde er überhaupt korrekt initialisiert? Hier müßte der Entwickler vom Gerätemanagement einen Statusbericht erhalten, aus dem er erkennen könnte, ob die Initialisierung geklappt hat. Wenn nicht, müßte er die Möglichkeit haben, den Treiber (d.h. den Knoten im Gerätemanagement) des Empfängers im laufenden Betrieb neu zu starten.

• Wenn die Initialisierung nicht klappen will, liegt ein Hardware-Problem vor, d.h. die Batterien, die den GPS-Empfänger mit Strom versorgen, sind leer, oder es ist ein Stecker aus seiner Buchse gerutscht. In diesem Fall bleibt dem Entwickler nichts anderes übrig, als wieder in sein Büro zurückzukehren und den Ladezustand der Batterien bzw. die Verkabelung zu überprüfen.

• Wenn die Initialisierung geklappt hat, aber trotzdem keine Positionsdaten geliefert werden, so hat der GPS-Empfänger unter Umständen keinen Kontakt zu ausreichend vielen GPS-Satelliten. Wenn das der Fall ist, muß der Entwickler einfach eine Weile

warten bzw. sich einen besseren Standort suchen. Auch hier müßte der Entwickler die Möglichkeit haben, einen Statusbericht vom Gerätemanagement anzufordern.

Aus diesen Praxiserfahrungen lassen sich nun eine Reihe von Anforderungen an die Entwicklungsumgebung ableiten:

1. Die Entwicklungsumgebung kann nicht auf dem Rechner laufen, auf dem die AR-Anwendung läuft. Anstelle dessen muß es möglich sein, sie auf irgendeinem Rechner laufen zu lassen, der eine Netzwerkverbindung zum mobilen AR-Gerät aufbauen kann.

2. Die Entwicklungsumgebung sollte auf einer möglichst großen Palette von Geräten laufen. Wie oben bereits erwähnt, sind Laptops für den Betrieb im Freien meistens ungeeignet, weil ihr Display in einer hellen Umgebung nicht oder nur schwer lesbar ist. Andere Geräte wie Mobiltelephone und PDAs sind dagegen für einen Einsatz im Freien konzipiert und besitzen reflektive Displays, die auch unter Sonnenlicht lesbar bleiben. Es wäre wünschenswert, wenn die Entwicklungsumgebung auch auf solchen Geräten verfügbar wäre.

3. Eine wichtige Aufgabe der Entwicklungsumgebung ist selbstverständlich, dem Programmierer die Werkzeuge zum Entwickeln von AR-Anwendungen zur Verfügung zu stellen. Im Falle des in dieser Arbeit vorgestellten Rahmensystems bedeutet das, daß die Entwicklungsergebung den Aufbau des Datenflußgraphen des Gerätemanagements und den Aufbau des VRML-Szenengraphen unterstützen muß.

Damit ist nicht gemeint, daß die Entwicklungsumgebung die Modellierung von 3D-Objekten erlauben soll – dafür gibt es perfekt spezialisierte Softwarepakete wie 3DStudio Max oder Maya. Anstelle dessen sollte die Entwicklungsumgebung das Zusammenstellen von Logikkomponenten und fertig modellierten 3D-Objekten zu einer AR-Anwendung anbieten, d.h. das Erzeugen und Modifizieren von Knoten und der Routes, die diese Knoten miteinander verbinden.

4. Eine weitere wichtige Aufgabe der Entwicklungsumgebung ist das Debugging, d.h.

die Fehlersuche bei laufender AR-Anwendung. Anders als bei klassischer Programmentwicklung heißt das bei dem hier vorgestellten Rahmensystem nicht, daß man schrittweise durch einen Code gehen kann und dabei Variablen beobachtet. Es bedeutet vielmehr, daß man die Graphen (Datenflußgraph des Gerätemanagements und VRML-Szenengraph) im laufenden Betrieb betrachten und modifizieren kann. Es sollte möglich sein, Knoten hinzuzufügen, zu entfernen oder zu modifizieren. Darüber hinaus sollte es möglich sein, Routes zwischen Knoten zu erzeugen und zu entfernen.

Der Entwickler muß die Möglichkeit haben, Informationen zum aktuellen Zustand von Knoten abzufragen, die zuletzt über Slots verschickten oder empfangenen Datenwerte anzeigen zu lassen, und unter Umständen selbst Datenwerte über die Entwicklungsumgebung zu erzeugen und in das System einzuschleusen.

Bei fast allen existierenden AR-Frameworks und Gerätemanagement-Systemen gibt es inzwischen integrierte User-Interfaces, die es erlauben, diese Systeme während des laufenden Betriebs zu konfigurieren und zu überwachen. Zum Teil erlauben diese User-Interfaces auch das Entwerfen und Debuggen von Anwendungen über das Netzwerk (Punkt 1). So besitzt z.B.

das Tinmith-System [35] einen integrierten Network File System (NFS)-Server, der es erlaubt, die Baumstruktur des Systems als Dateisystem auf anderen Rechnern zu mounten und dann mit den normalen Werkzeugen zum Verwalten von Dateien zu bearbeiten. Die

„DWARF Interactive Visualization Environment“ [92] erlaubt es, über die in DWARF integrierten CORBA-Mechanismen den aktuellen Zustand des Systems zu visualisieren und zu modifizieren. VR Juggler kann über das in Java implementierte „VjControl“-Programm [52] zur Laufzeit über eine Netzwerkverbindung kontrolliert werden. Der Nachteil dieser

Lösungen ist, daß sie entweder nicht wirklich anwenderfreundlich sind (wie der in Tinmith integrierte NFS-Server) oder die Installation einer speziellen Softwarekomponente auf dem Entwicklungs- bzw. Debugging-Rechner erfordern, die natürlich auf die jeweilige Plattform portiert werden muß.