Modifikationen des Archeoguide-Systems

Abbildung 57: Transparenzregelung des Overlay-Bildes

Schließlich befinden sich im dritten Abschnitt noch drei Sensor-Knoten („plusButtonSensor“,

„minusButtonSensor“ und „selectButtonSensor“, die den Zustand der Knöpfe vom nVision VB-30 Head Mounted Display aus dem Datenflußgraphen empfangen und an das Controller-Script weiterleiten. Über diese drei Buttons wird das User-Interface des Systems gesteuert, d.h. man konnte z.B. die Transparenz des Overlay-Bildes verändern (Abbildung 57), die Lautstärke der Audioausgabe regeln, Landkarten des Geländes einblenden etc. Das gesamte User-Interface ist Teil des VRML-Szenegraphen und wird über Inslots und Outslots vom Controller-Script gesteuert. Der zugehörige Code wird hier aus Gründen der Übersichtlichkeit nicht abgedruckt.

Neue Bestandteile der XML-Darstellung des Datenflußgraphen für die Benutzung eines Gamepads anstelle der Buttons des VB-30 HMD

...

<Node type="Joystick" label="Joystick">

<Parameter name="Device" value="0"/>

<ExternalRoute internal="*" external="{NamespaceLabel}/{SlotLabel}"/>

</Node>

<ExternalRoute internal="Joystick/Button #1" external="Plus-Button"/>

<ExternalRoute internal="Joystick/Button #2" external="Minus-Button"/>

<ExternalRoute internal="Joystick/Button #3" external="Select-Button"/>

...

Genau genommen ist es gar nicht notwendig, den VB30-Knoten aus dem Datenflußgraphen zu entfernen. VB30-Knoten und Joystick-Knoten könnten auch problemlos nebeneinander existieren. Wenn das VB-30-HMD angeschlossen ist, liefert der VB30-Knoten die Button-Stellungen, während der Joystick-Knoten kein Gamepad findet und seine Arbeit daher nicht aufnimmt. Ist dagegen ein Gamepad angeschlossen, so ist es genau andersherum: Der VB30-Knoten findet kein VB-30-HMD und nimmt seine Arbeit nicht auf, während der Joystick-Knoten die Button-Stellungen des Gamepads liefert. Man erinnere sich, daß es das Konzept des Datenflußgraphen erlaubt, daß sich beliebing viele Outslots mit beliebig vielen Inslots verbinden können. In diesem Fall sind die Button-Inslots des VRML-Szenengraphen mit jeweils zwei Outslots (vom VB30-Knoten und vom Joystick-Knoten) verbunden, von denen aber je nach Hardwarekonfiguration nur jeweils einer Werte liefert. Es ist also ohne weiteres möglich, bei geschicktem Aufbau des Datenflußgraphen mehrere Hardwarekonfigurationen mit ein- und demselben Graphen zu behandeln.

Man beachte darüber hinaus auch, daß sich die notwendigen Modifikationen auf den Datenflußgraphen beschränken. Die VRML-Szene und die in ihr enthaltenen Skripte werden nicht verändert. Das bedeutet, daß die eigentliche Anwendung nicht modifiziert werden muß, wenn sich die Hardwarekonfiguration ändert – ein wichtiger Vorteil von Systemen, die auf einem Datenflußkonzept beruhen, das Änderungen an der Hardware weitgehend vor der Anwendung verbergen kann.

Eine weitere Modifikation des ursprünglichen Archeoguide-Systems bestand im Einsatz von Differential GPS (DGPS). DGPS ist eine Technik, die es erlaubt, die Genauigkeit der vom GPS-Empfänger gelieferten Positionsdaten drastisch zu vergrößern. Dazu setzt man eine Basisstation ein, die sich an einem genau bekannten Standpunkt befindet und ständig ihre Position per GPS bestimmt. Da der korrekte Standpunkt bekannt ist, kann die Basisstation die Abweichung der GPS-Position vom tatsächlichen Standpunkt und somit den aktuellen Fehler des GPS-Systems bestimmen. Da dieser Fehler für alle GPS-Empfänger, die sich in der Nähe der Basisstation befinden, identisch ist, kann die Basisstation Korrekturdaten an diese GPS-Empfänger übermitteln, die es diesen erlauben, den Fehler ihrer eigenen Positionsbestimmung zu verringern. DGPS-Systeme sind also nicht mehr nur von den GPS-Satelliten abhängig, sondern auch von zusätzlicher Hardware am Boden (der Basisstation). In der näheren Umgebung dieser Basisstation können mobile Geräte dadurch ihre Position mit drastisch erhöhter Genauigkeit bestimmen.

Es stellt sich jedoch das Problem, wie man die Korrekturdaten der Basisstation an die GPS-Empfänger übermittelt. Das Format der Korrekturdaten selbst ist im RTCM-Standard festgelegt, d.h. die von der Basisstation gelieferten Korrekturdaten können von allen GPS-Empfängern, die RTCM unterstützen, direkt verarbeitet werden. Auch für die Übertragung der RTCM-Daten gibt es ein Standardverfahren, bei dem die Basisstation ein Funksignal ausstrahlt, das von GPS-Empfängern empfangen werden kann. Leider besitzen nur wenige hochpreisige High-End-GPS-Empfänger eine solche Empfangseinheit für RTCM-Daten. Da

das Archeoguide-System aber ohnedies schon über ein WLAN mit einem zentralen Server verbunden ist, wurde entschieden, die Korrekturdaten der Basisstation über dieses WLAN zu übertragen und damit die Kosten der mobilen AR-Systeme gering zu halten.

Der Umsetzung dieses Konzeptes kommt zugute, daß der Datenflußgraph völlig netzwerk-transparent ist. Es wurden daher zwei neue Knotentypen implementiert, nämlich der

„RTCMReader“ und der „RTCMWriter“. Der RTCM-Reader liest die RTCM-Korrekturdaten von einer an die serielle Schnittstelle des Archeoguide-Servers angeschlossenen DGPS-Basisstation und verschickt sie über einen „Data“-Outslot. Der RTCM-Writer empfängt RTCM-Korrekturdaten über einen „Data“-Inslot und überträgt sie an einen an die serielle Schnittstelle angeschlossenen GPS-Empfänger (diese serielle Schnittstelle ist bei allen bekannten GPS-Empfängern nicht identisch mit der Schnittstelle, die die NMEA-Daten liefert – es tritt daher kein Zugriffskonflikt mit dem NMEA-Knoten auf). Dazu wurde ein spezieller Datentyp („RTCMData“) implementiert, der Blöcke von RTCM-Daten aufnehmen kann. Wie im 3. Kapitel beschrieben, unterstützt der Datenflußgraph beliebige Datentypen und nicht nur Geräteklassen. An diesem Beispiel kann man sehen, wie wichtig dieses Grundkonzept in der Praxis ist – auf welche herkömmliche Geräteklasse hätte man die RTCM-Datenblöcke abbilden können? Darüber hinaus wurden wie im 4. Kapitel beschrieben ein Encoder und ein Decoder geschrieben, die die RTCM-Datenblöcke in eine netzwerk-transparente Darstellung umwandelten und aus einer solchen wieder rekonstruierten.

Netzwerk

. . .

Data RTCMData

RTCMReader GPS Reference Station

RTCMWriter Mobile Unit 1

Data RTCMData

RTCMWriter Mobile Unit 1

Data RTCMData

RTCMWriter Mobile Unit 1

Data RTCMData

Abbildung 58: Übertragung von RTCM-Daten über das WLAN

Die Übertragung der RTCM-Daten ist jetzt mit Leichtigkeit zu bewerkstelligen. Auf dem Server wird ein Datenflußgraph, bestehend aus RTCMReader-Knoten und Network-Knoten (der die Netzwerktransparenz herstellt), aufgebaut. Auf den mobilen AR-Geräten wird der vorhandene Datenflußgraph um einen RTCMWriter-Knoten und ebenfalls um einen Network-Knoten erweitert. Darüber hinaus wird auf den mobilen Geräten eine Route angelegt, die die Outslots des RTCMReader-Knotens auf dem Server über das Netzwerk hinweg mit den Inslots der RTCMWriter-Knoten verbindet. Abbildung 58 stellt dies schematisch dar. Auch an dieser Stelle sei darauf hingewiesen, daß ein Outslot mit beliebig vielen Inslots verbunden sein kann. Daten, die in einen solchen Outslot geschrieben werden, werden an alle angeschlossenen Inslots übertragen.

Die XML-Beschreibung des Datenflußgraphen auf der Server-Seite sieht folgendermaßen aus:

XML-Beschreibung des Datenflußgraphen der DGPS-Basisstation

<?xml version="1.0"?>

<HID versionMajor="1" versionMinor="0">

<Node type="RTCMReader" label="RTCMReader">

<Parameter name="Device" value="0"/>

<ExternalRoute internal="*" external="{NamespaceLabel}/{SlotLabel}"/>

</Node>

<Node type="Network" label="Network">

<Parameter name="Prefix" value="DGPSBase/{SlotLabel}"/>

<ExternalRoute internal="*" external="{SlotLabel}"/>

</Node>

</HID>

Auf der Seite der mobilen AR-Geräte wird folgendes zur XML-Beschreibung des Datenflußgraphen hinzugefügt:

Neue Bestandteile der XML-Darstellung des Datenflußgraphen auf den mobilen für den Einsatz von DGPS

...

<Node type="RTCMWriter" label="RTCMWriter">

<Parameter name="Device" value="3"/>

<ExternalRoute internal="*" external="{NamespaceLabel}/{SlotLabel}"/>

</Node>

<Route from="DGPSBase/RTCMReader/Data" to="RTCMWriter/Data"/>

<Node type="Network" label="Network">

<ExternalRoute internal="*" external="{SlotLabel}"/>

</Node>

...

Der auf der Serverseite vorhandene Outslot „RTCMReader/Data“ wird über die auf Server- und Clientseite vorhandenen Networkknoten unter dem Namen

„DGPSBase/RTCMReader/Data“ auf allen mobilen AR-Geräten in den Datenflußgraphen eingefügt. Eine Route verbindet den Outslot mit dem jeweiligen „RTCMWriter/Data“-Inslot des mobilen AR-Geräts. Auf diese Weise werden die RTCM-Korrekturdaten an die jeweiligen GPS-Empfänger der Geräte übertragen.

Auch bei dieser Erweiterung des Systems kann man wiederum zwei Punkte feststellen:

1. Es ist keine Modifikation der eigentlichen Anwendungslogik im VRML-Code und den zugehörigen Scripten notwendig. Die Änderungen finden ausschließlich im Datenflußgraphen statt.

2. Die vorgenommenen Änderungen am Datenflußgraphen verhindern nicht die Funktionsfähigkeit des Systems, wenn am Einsatzort des Archeoguide-Systems keine DGPS-Basisstation vorhanden ist, oder wenn der von den mobilen AR-Geräten eingesetzte GPS-Empfänger keine RTCM-Daten verarbeiten kann. Im ersten Fall gibt es einfach keinen Outslot, der die RTCM-Daten liefert. Die Inslots der RTCM-Writer auf den mobilen Einheiten empfangen keine RTCM-Daten, und es werden keine RTCM-Daten über die serielle Schnittstelle an den GPS-Empfänger übertragen. Das verhindert nicht die korrekte Funktion des Gesamtsystems. Im zweiten Fall werden die RTCM-Writer seine Arbeit nicht aufnehmen, und die auf den Inslots eintreffenden RTCM-Daten werden ignoriert.