Ubiquitous Tracking
PoseData Migration Howto
You can find detailed information about our migration plans from current
PoseData to Ubitrack on the
ProjectUbitrackMigration page.
What it's about
Introduction
Augmented Reality (AR) applications are highly dependent from accurate
and precise tracking data. Since current tracking technologies do not
always provide such information everywhere in real-time application
developer must combine certain trackers together to minimize the
disadvantage of one tracker by another. These sensor networks can then
be used to deliver positional relation information of objects to the
application which then can be evaluated.
Currently most AR application bring along their own customized
solution of this problem. However these solutions are hardly reusable
in other systems. This inhibits the development of large-scale sensor
networks because there are no standard interfaces between these
technologies. By introducing the
Ubitrack framework it is
possible to form ubiquitous tracking environments which may consist
of several sensor networks.
The Ubitrack framework
The spatial information is modeled by a
Spatial-Relationship
(SR) graph. The nodes of this graph are all identifiable objects in
the world, the edges represent the spatial information of two node
object. When we want to know the relationship of one object to another
we traverse all edges from one to the other and evaluate all
information on these paths.
This framework is an abstraction layer between the hardware sensor API
and the application. This enables the applications to use unified
interfaces to access position data.
The main idea is that this framework is distributed over a large area
of sensor networks combining several hundreds (or thousands) of
sensors together. This amount is too large to be handled by one
central component so it is necessary to split the framework into
suitable components which can easily be distributed over the
network. By using a completely de-centralized architecture the
addition of new components into running systems should become very
easy. However this approach raises new problems which must be solved
first:
- Scalability: Since we are speaking of several hundreds of different sensors the framework must be very scalable to suit this large amount of components.
- Migration: Sensor networks are not always stationary set-ups. There are many mobile tracking technologies, for example a mobile ARToolkit setup. These mobile trackers must be integrated into stationary systems when there is a demand for them. To optimize the performance the migration of framework components into these set-ups should not disturb the real-time efficiency.
- Bootstrapping: Another problem which is related to the easy migration of components is the bootstrapping problem. When a user enters a new sensor network, he/she must be identified as an Ubitrack object and his/her mobile trackers must be integrated so that the SR graph can be updated with the new informations.
Scenario (not a demo!)
- Two visitor Alice and Bob want to meet at the parking site of the Forschungszentrum Garching. They are wearing a mobile ARToolkit setup with wireless LAN running Ubitrack. Additionally Alice has a GPS tracker. Both of them have their own local SR graph consisting of their mobile setup.
- When both are reaching the wireless LAN area of each other the Ubitrack systems connect together. First position measurements is done by WLan, which leads to a connection of the subgraphs. Since both are wearing ARToolkit markers, the personal maker information is exchanged and the tracking system initialized. When the cameras can track the markers, the Ubitrack SR graphs are connected by a new edge with higher precission. After the combination of the graphs the visitor who has no GPS tracking device can now receive GPS coordination relativ to him. This setup would be ready to do collaborative Augmented Reality.
- Now they go towards the FMI building. When they reach the wireless LAN area the Ubitrack system of Alice and Bob now connects with the one of the building. Using the wireless LAN access points, the Ubitrack system of the building give give a first position estimation of Alice and Bob. The SR graphs are now linked together.
- When they go inside the building, the motion detector at the door detects two anonymous objects. In combination with the measurements those objects are mapped to Alice and Bob. This leads to a refinement of the position data.
- When they reach the AR lab Alice and Bob can automatically be integrated in running Augmented Reality applications, for example Sheep. They can automatically use the tracking setup in the AR Lab and the AR application is supported by Alice's and Bob's wearable trackers.
People
This is a list of all academic partners currently involved in the project.
- TU München
- TU Wien
- Cambridge University Engineering Department
Literature
Check out (and extend!) the
AugmentedRealityBibliography.
UbitrackRelevantPapers
Timeline
| Time | Activity |
|---|
| 15 Jan 2004 | Start of TUM Diplomarbeiten |
| Until workshop (2004-02-06) | Definition of a concrete scenario for the demo, Conceptual model of Ubitrack in DWARF: service model, finding suitable attributes |
| Salzburg Workshop 6-8 Feb 2004 | Specification of API and interfaces for the Ubitrack layer |
| February - March | First implementation |
| Cambridge Workshop 22-25 Mar 2004 | ... |
| | Probably modifaction in the middleware for more efficiency |
| April | Integration with other parts, probably optimisation of components |
| 14 May 2004 | ISMAR paper submission deadline |
| 25 May 2004 | Final thesis demo |
| _end of May | Cambridge Math Workshop? |
| 31 May 2004 | Short proposal deadline |
| June - July | writing thesis |
| 15 Jul 2004 | Thesis submission deadline |
| Sep 22/23 | Munich Workshop |
| ?? ?? 2004 | Full proposal submission deadline |
Work Products
Common APIs
The Ubitrack project is a collaboration between TU Vienna and TU München. The final goal is to provide a reusable concept that can be deployed in many locations, leading to infinite fame of all participating developers. Thus, we have to define common APIs to ensure maximum compatibility between independently developed subsystems.
Based on the three-layer architecture mentioned above (Application - Ubitrack - Sensors), we have the following APIs:
Project Meetings
Weekly meeting protocols:
Trash.ProjectUbitrackMeeting031204 |
2003-12-22 |
2004-01-25 |
2004-02-02 |
2004-02-16 |
2004-03-04 |
2004-03-11 |
2004-03-18 |
2004-04-23
| Home | People | Projects | Publications | Teaching | Changes | Index
Cleanup: ProjectUbitrack .