Ubiquitous Tracking Implementation ConceptsThomas Pintaricpintaric@ims.tuwien.ac.at

SLIDE 2/15

THOMAS PINTARICPINTARIC @ IMS.TUWIEN.AC.AT

Implementation Concept (Overview)

SLIDE 3/15

THOMAS PINTARICPINTARIC @ IMS.TUWIEN.AC.AT

Definitions

Framework A number (1..n) of software components (locale

managers) encapsulating the up-to-date ’relationship topology’ graph Q.

Controllers Software components running on every machine

whose local sensor hardware takes part in the framework.

They build and manage inter-dependent, distributed data-flow graphs.

They offer interfaces for applications to query the framework and obtain the corresponding pose estimates.

Database A repository of infrastructure information in BAUML

(Building AUgmented Modelling Language – an XML schema) syntax.

SLIDE 4/15

THOMAS PINTARICPINTARIC @ IMS.TUWIEN.AC.AT

Types of Communication / Data-flow

SLIDE 5/15

THOMAS PINTARICPINTARIC @ IMS.TUWIEN.AC.AT

Dynamically Shared Data-Flow Graphs

SLIDE 6/15

THOMAS PINTARICPINTARIC @ IMS.TUWIEN.AC.AT

Implementation Concept (revisited)

SLIDE 7/15

THOMAS PINTARICPINTARIC @ IMS.TUWIEN.AC.AT

(Select) concepts in need of further discussion…

Handover Can initially be avoided by using a single locale

manager to store the entire graph Q and to handle all queries (> equivalent to a central server approach).

In the long run, I would propose a scheme based on evaluating per-locale transition probabilities (by introducing containment relations) for a set of candidate target locales.

Sensor Registration

Database Read-only (bootstrapping + sensor registration), or

should we allow back-propagation of measurements?

SLIDE 8/15

THOMAS PINTARICPINTARIC @ IMS.TUWIEN.AC.AT

Cambridge Design Proposal

SLIDE 9/15

THOMAS PINTARICPINTARIC @ IMS.TUWIEN.AC.AT

Overlap between design approaches atTU-Munich and TU-Vienna

Similarities UbiTrack controller components and locale managers

will be implemented as DWARF (Distributed Wearable Augmented Reality Framework ) services.

Common interface for applications to issue queries.

Common set of data types describing measurements and their attributes.

Common simulation environment.

Differences Independent implementation of the flow-scheduling

framework (OpenTracker 2.0 vs. DWARF network).

OpenTracker 2.0A modular, dynamic and general-purpose data-flow scheduling framework.

SLIDE 11/15

THOMAS PINTARICPINTARIC @ IMS.TUWIEN.AC.AT

OpenTracker 1.x

A quick summary of OpenTracker 1.x features:

Flow-scheduling framework for tracking data Implements the traditional pipes & filters data-flow

model Supports both push and pull data transport

mechanisms Based on XML/DOM Support for many popular tracking devices

…. and OpenTracker 1.x shortcomings:

Limited to fixed complex data type (Pos,Rot,Buttons) Does not support runtime reconfiguration

SLIDE 12/15

THOMAS PINTARICPINTARIC @ IMS.TUWIEN.AC.AT

OpenTracker 2.0 Requirements

Interface for Dynamic Reconfiguration / Graph Searching:

Interface for runtime reconfiguration:- locking (i.e. flushing) subgraphs- adding/removing nodes- connecting/disconnecting pins

Interface for graph searching:- search for particular subgraphs

Traversal scheduling:

Implement a scheduler (ACE Reactor).

Multi-modal events:

Model events as a map from a name to a typed data value (see next slide).

SLIDE 13/15

THOMAS PINTARICPINTARIC @ IMS.TUWIEN.AC.AT

Multi-modal events

Samples can be augmented, but existing sample data cannot be modified.

SLIDE 14/15

THOMAS PINTARICPINTARIC @ IMS.TUWIEN.AC.AT

An initial set of data types(summary of yesterday’s dicsussion)

Measurements:

PosMean > float[3] RotMean > float[4] ObservedObjectID > string

Attributes:

Time > float Latency > float Certainty > float (0..1) PosStdDev > float[3,3] RotStdDev > float[?]

Questions?Thanks for listening anyways…