Proseminar: Anwendung für Augmented Reality

1. Proseminar: Anwendung für Augmented Reality Thema: Systeme, ArchitekturenRolf Siebachmeyer (siebachm@in.tum.de)Betreuer: Marcus TönnisDatum: 07.06.2005 Rolf Siebachmeyer

2. Quellen • Martin Bauer (2001), Design of a Component-Based AR Framework • Joseph Newman (2001), AR in a Wide Area Sentient Environment • http://www.uk.research.att.com/projects.html • http://www.augmentedreality.de • http://www.corba.org • Marcus Tönnis (2003), Data Management for AR • http://atbruegge27.informatik.tu-muenchen.de/teaching/ws01/AR-Vorlesung/ Rolf Siebachmeyer

3. Gliederung • Einleitung • The Sentient Environment • DWARF (Distributed Wearable Augmented Reality Framework) • Vergleich und Ausblick Rolf Siebachmeyer

4. Sichten Wer braucht was? • Projektmanager • Entwickler • Benutzer Rolf Siebachmeyer

5. Eigenschaften Was sollte eine Architektur bieten? • Kosten • Zeit (Entwicklung und Erweiterung) • Erweiterbarkeit • Konfigurierbarkeit • Wiederverwendbarkeit • Sicherheit und Verlässligkeit • Laufzeitverhalten • … Rolf Siebachmeyer

6. Unterschiedliche Architekturen • Client-Server (Sentient Environment) • Verteilte Dienste (DWARF) • (Monolithic,…) Rolf Siebachmeyer

7. The Sentient Environment Was ist das „Sentient Environment“? • AR-Umgebung zu Testzwecken von AT&T Laboratories Cambridge • Etwa 1000m² Fläche (ca. 50 Räume) • Wird genutzt von 50 Mitarbeiter • „Sentient Computer System“ • Positionsbestimmung von Objekten mit „Bats“ Rolf Siebachmeyer

8. Bats • Positioning Device (Ultraschall) • Ultraschallsender, Radio-empfänger, eindeutige ID • Positionsbestimmung zu95% auf 3cm genau • Lebensdauer der Batterie etwa12 Monate Rolf Siebachmeyer

9. Positionsermittlung • Anfrage von Sentient System • Ultraschallempfänger an der Decke • Entfernung (Bat - Empfänger) überFlugzeit von Ultraschall • Signal muss von min. 3 Empfängernerkannt werden  Position • Mehr als ein Bat am Objekt Bestimmung der Orientierung Rolf Siebachmeyer

10. Sentient (Computing) System • Das World model besteht aus • Personen • Realen Objekten (Telefonen, PCs, Möbel, Wände,…) • Virtuellen Objekten • Sentient System verwaltet World model • Ein Software-Objekt pro realem/virtuellem Objekt (ca. 1900) • Gibt Informationen an Nutzer/Applikationen weiter Rolf Siebachmeyer

11. Zugang zur AR-Umgebung • Head-mounted Display System • Batportal Rolf Siebachmeyer

12. HMD System • Helm mit drei montierten Bats • Optical see-through HMD • Thinkpad mit WLAN Karte • Akkus für 3 - 4h Nutzung Rolf Siebachmeyer

13. Tracking • Informationen über Umgebung (Teile des World models) von Sentient System • Position von bewegten Objekten im World model ungenau (nur 2-3 updates pro Sek.) • Kurze Intervalle werden daher mit eigener Trackingeinheit überbrückt • Bei Update des eigenen Software-Objekts (im World model) wird die Position korrigiert Rolf Siebachmeyer

14. Batportal • „kleine alternative“ zum HMD System • Handheld mit • WLAN Karte • aufmontiertem Bat • Weiterer Bat am Nutzer Rolf Siebachmeyer

15. Tracking • Position von Handheld undNutzer bekannt • Dargestellt wird nur virtuelleRealität • Keine weitere Trackingeinheit Rolf Siebachmeyer

16. Blick durch HMD / auf Batportal Device Rolf Siebachmeyer

17. Architektur • Im World model sind alle realen/virtuellen Objekte als Software-Objekte abgespeichert • Sentient System • Verarbeitet und filtert Informationen • Verwaltet das World model • Gibt Informationen an Nutzer/Applikationen weiter • Positionsdaten • Beschreibungen • Sentient System ist zentraler Rechner Rolf Siebachmeyer

18. Client-Server-System • Sentient Computing Systemist „Server“ • Personen in der AR-Umgebung sind „Clients“ • Informationen über das Worldmodel / Beschreibungen vonObjekten sind nur über dasSentient System verfügbar Rolf Siebachmeyer

19. Updaten eines Software-Objekts • Sentient System empfängt Positionen von 3 Bats (20ms timeslots) • Bei großen Abweichungen wird neu getrackt • Signale werden gefiltert (Spherical linear interpolation) • World model wird aktualisiert • Insgesamt schafft das Sentient System etwa 150 Updates pro Sekunde (2-3 Updates pro Person) Rolf Siebachmeyer

20. Vorteile - Nachteile • Vorteile: • Wenig Equipment am User (UbiComp) • Viel Rechenleistung für spezialisierter Anwendung • Nachteile: • Unsicher • Kommunikation immer über Server • Geringe Mobilität (nur in der Nähe des Servers) Rolf Siebachmeyer

21. DWARF (Distributed Wearable Augmented Reality Framework) Was ist DWARF? • AR-Framework bestehend aus verteilten Diensten • Die wichtigsten Elemente • Conceputal architecture • Main services • Middleware • Prototyp mit Demoanwendung (Dezember 2000) Rolf Siebachmeyer

22. Demo-System • Rucksack mit 2 Notebooks • See-through HMD • Kamera (optisches Tracking) • GPS-Empfänger • Mikrophon • WLAN/Bluetooth Rolf Siebachmeyer

23. Demo-System • Campus-Navigation zu einembestimmten Raum • Optisches Tracking innerhalb derGebäude • GPS zum Tracken außerhalb • Einblenden von 2D/3D-Karten • Aufgeben eines Druckauftrags,sobald der Campus erreicht Rolf Siebachmeyer

24. Ansatz – Verteilte Dienste • Framework besteht aus (Software) Diensten die auf eigener Hardware laufen • Zusammengehörige Soft- und Hardware  Modul • Module sind über ein Netzwerk verbunden • …und werden am Körper getragen • …oder sind externe Geräte (intelligente Umgebungen) • Dienste finden und verbinden sich dynamisch und bilden ein komplettes System Rolf Siebachmeyer

25. Elemente • Conceputal architecture • Beschreibung der grundsätzlichen Struktur von AR-Systemen • Main Services • Dienste welche die Grundfunktionalität für ein AR-System liefern (tracking, world model, …) • Middleware • Kommunikation zwischen Diensten Rolf Siebachmeyer

26. Architektur • Vier Gebiete • Erhalten von Informationen • Interaktion mit User • Externe Dienste • Modellieren der World • Anwendung Rolf Siebachmeyer

27. Main Services • Liefern Grundfunktionalität für AR-Anwendungen • Tracking • World model • User interface • … • Können in der Regel wieder verwendet werden Rolf Siebachmeyer

28. World • World model • Tracking subsystem Rolf Siebachmeyer

29. World model • Informationen über reale/virtuelle Objekte • Berechnung von relativer Pose zwischen Objekten • Laden neuer Umgebungen Rolf Siebachmeyer

30. Tracking subsystem • Liefert Pose-Informationen von Objekten • „Tracking manager“ kombiniert Poses mehrerer Tracker oder filtert Poses • QoS-Parameter • Genauigkeit • Updaterate • Verzögerung • … Rolf Siebachmeyer

31. Middleware - Aufgaben • Finden neuer Dienste • Dynamisches verbinden von Diensten • Needs • Abilities Rolf Siebachmeyer

32. Service Manager • Bietet unter anderem dieseFunktionalität • Ein Service Manager proModul • Alle Service Manager sindgleich • Beim Start melden sich Services bei lokalem Service Manager (needs und abilities) Rolf Siebachmeyer

33. Verbinden von Diensten • Überprüfen aller needs undabilities • QoS-Eigenschaften • Herstellen einer Verbindung zwischen beiden Diensten (connectors) • Nach dem Verbinden ist der Service Manager nicht mehr in die Kommunikation verwickelt • Bei Bedarf kann der Service Manager die Verbindung wieder unterbrechen Rolf Siebachmeyer

34. Vorteile - Nachteile • Vorteile • Wiederverwendung • Erweiterbarkeit • Benutzerfreundlich („Plug-and-Play“) • Nachteile • Viel Equipment am User • Akkulaufzeit Rolf Siebachmeyer

35. Vergleich und Ausblick • Es gibt keine „One-size fits it all“-Lösungen • Spezielle Anwendung  Client-Server • Allgemeine Anwendung  Verteilte Systeme Rolf Siebachmeyer

36. Vergleich und Ausblick • Verteilte Systeme werden vermutlich „das Rennen machen“ • Miniaturisierung • Client-Server wird immer mehr verdrängt • Jede AR-Anwendung passt in ein allgemeines Schema • Ausnahme: Hochspezialisierte Anwendung die viel Rechenleistung benötigen Rolf Siebachmeyer

37. Dankefür EureAufmerksamkeit Rolf Siebachmeyer