Studierstube Augmented Reality Project

   Home       Research       Development       Projects       Search   

SignPost - Mobile AR Navigation System

SignPost is a Studierstube application that is able to guide a person through an unfamiliar building. The person wears a mobile navigation equipment that consists of:

  • a head mounted Glasstron optical stereo see-through display
  • a helmet with an Intersense InterTrax2 inertial tracker
  • a FireWire camera
  • a backpacked notebook computer with an accelerated 3D graphics chip
  • a wrist pad that allows user input

The see-through glasses enable the user to see the real environment of the room in which he is currently standing. SignPost allows the user to select a destination within the building and guides him or her to the desired destination by overlaying hints (i.e. direction arrows and a wireframe model of the room and its portals) on the user's view of the scene through the glasses. The application searches the shortest path starting from his or her current position and directs the user along that path to the selected room.

To determine the user's current position, SignPost of course needs some sort of tracking.
As we cannot rely on GPS or similar positioning systems inside a building, tracking of the user is done with ARToolkit markers and the FireWire camera in combination with the Intersense inertial tracker which is particularly dedicated for fast changes in the orientation of the user. Details of tracking are described below.

Interaction

As mentioned before, the user wears a wrist pad, that allows him or her to interact with the SignPost navigation system. Whenever the wrist pad is brought into the user's view a WIM model ("world in miniature") is overlaid onto the scene, providing the person, who wants to be guided through the building, with an overview of all rooms on the floor. The user's current position is displayed as a yellow room, whereas the destination room is shown in red. The path to the destination is shown is highlighted in cyan.

At startup of SignPost, the application (of course) has no knowledge of the room in which the user is. The current position is either determined by viewing a unique marker (described in section 'Marker re-use') or by selecting the current room on the wrist pad. Then the person can select the desired destination. The wrist pad provides the following options:

Select Destination   The user can enter the desired destination after selecting this button. A list of all rooms on the floorplan is presented, from which he or she can choose the one he or she wants to be guided to.
Select Current Room   Whenever the current position of the person cannot be recognized by an ARToolkit marker (or in case the wrong room was recognized), the user can tell SignPost his or her current room via this option.
Toggle Wireframe   By default, the user is guided by arrows, which are displayed on the see-through glasses and direct the user to the next door or portal he or she should go.
Additionally, via this option a wireframe model of the current room and its portals can be overlaid onto the scene, to allow monitoring of the alignment of the computer model with the real scene.

After selecting a destination room, SignPost queries its own Pathfinder-component to find the shortest path from the current position to the selected destination. The Pathfinder relies on an adjacent graph, which is built at startup from the floorplan file (see below), and returns the distance of the shortest path as well as a list of the portals and rooms, which have to be passed on the way to the destination room. Based on that path and the geometry information of the floorplan, the SignPost system guides the user through the building by providing him or her hints on the see-through display.

Navigation Hints

These are the navigation hints that are overlaid on the user's view through the glasses:

The WIM (world in miniature) model is attached to the wrist pad and always shows a full view of the floorplan, with the person's current position (yellow), the path he or she has to go (cyan) and the destination (red).
The WIM model does not permanently cover the screen; the user can bring the WIM into his view by moving his arm with the wrist pad in front of his eyes.
Forward arrow: The next door or portal is straight forward.
Left arrow: The user should turn left to find the next door or portal.
Right arrow: The user should turn right to find the next door or portal.
U-Turn: Wrong direction - the user has to turn around to find the next door or portal.
Wire frame: The three-dimensional geometry information of the rooms and portals derived from the floorplan file can be displayed as well. The edges of the room geometry should be aligned with the edges of the real environment. As there sometimes appear jitter or large displacements in the overlay, the wire frame is optional and can be turned on and off by a button on the wrist pad.

Floorplan

SignPost relies on a floorplan, that holds three-dimensional geometry information of the rooms within the building, as well as information of ARToolkit marker placement (see 'Tracking'), in order to allow the application to determine the current position of the user within a room.

SignPost (as well as Studierstube) works with OpenInventor scene graphs for displaying 3D geometry. The geometry of the rooms and portals is directly loaded from an OpenInventor (.iv) file, which makes changes and extensions to the building information very flexible. However, data acquisition was very work intensive, as for each room and portal several coordinates have to be provided (plus the offset of the room within the floor) and additionally the position as well as the orientation of a lot of ARToolkit markers has to be measured and stored. Thus, editing all this information in a single textual file is not very comfortable.

Map Viewer

To overcome this problem, we think about an XML file format to make the building geometry information more structured. Also, adjacency information - e.g. which room has a portal to another room - could be saved more logically. However, there would still be a textual file that someone has to edit.

The most convenient solution will be a Map Editor that allows graphical interaction, such as interactive room and marker placement with the mouse. Until then, we provide a Map Viewer tool, which shows the currently stored floorplan together with the marker positions, their orientation and ID numbers.
The Map Viewer enables controlling the information stored in the floorplan file; it allows zooming as well as three-dimensional rotation of the building geometry.
Consequently, someone who does changes or extensions to the floorplan can immediatly check, whether his or her changes make sense and if everything is placed on the correct position. Without this tool, errors in the floorplan may hardly be found in the SignPost application and there may be strange results while guiding a user within the building ...

Tracking

Tracking of the person who uses the SignPost navigation system is done by a combination of optical and inertial tracking. In all rooms and hallways, which are covered by our floorplan, ARToolkit markers were mounted on the walls: at least one marker per wall, on larger walls one marker every 2 - 3 meters. An ARToolkit marker consists of a black square frame filled with some kind of a pattern. The patterns must have no rotational symmetry, have to be sufficiently distinct and have to be trained with ARToolkit in order to be recognized. ARToolkit - the Augmented Reality Toolkit - is an external component, which provides SignPost (through OpenTracker within the Studierstube framework) with optical tracking data.

The FireWire camera that resides on the user's helmet delivers a video stream to ARToolkit, which detects the markers in the video image. According to the size and orientation of the marker on the video image, it is able to compute the relative position of the user in respect to the marker. By combining the relative marker location and the positional and geometry information given in the floorplan file, the user's movement within the environment can be tracked with certain accuracy.

The Intersense inertial tracker, also mounted on the user's helmet, is able to track the user's orientation. It provides more frequent updates than the ARToolkit tracking and therefore is optimal for rapid movements of the user's head. Besides, it is also suited for filling gaps in tracking, e.g. when optical tracking failed or no marker is visible in the user's line of sight.

Marker re-use

In order to allow reasonable tracking, ARToolkit markers have to be placed every 2 - 3 meters. Deploying markers on our floor, which covers about 25 rooms and long hallways, would require several hundred different marker patterns to be created and trained for ARToolkit. The more markers we use, the higher the degree of similarity will be. A large set of markers also increases the search space that has to be compared by ARToolkit. Consequently, a large amount of markers leads to a decrease in performance and/or a higher number of false recognitions.

To overcome this problem, we developed a marker partitioning-scheme that allows re-using sets of marker. The idea is, that if the tracking system knows the user's current location, it can rule out large parts of the building because they will not be visible to the camera. Thus, for two areas, which are not visible to each other, it becomes possible to use the same set of markers. Based on the room models in the floorplan file, the application builds an adjacent graph using the rooms as nodes and the portals between rooms as edges. In addition to the portals representing logical connections, further edges that represent a line-of-sight between two rooms are added. An example of this adjacent graph is depicted on the left.

With that approach, we can generate a minimal number of disjoint sets of markers. Two rooms with a connection in the adjacent graph described above must have disjoint sets of markers. Otherwise the camera tracking system cannot decide which room a certain marker belongs to, if both instances are visible from one room. Rooms that have no connection in the adjacent graph can use the same set of markers (i.e. markers can be re-used).

This approach improves performance in two ways: 1) The overall amount of markers is minimized, which reduces false recognitions and minimizes the search space of ARToolkit. 2) Starting at a given room position, the system has only to track markers assigned to the current room and the neighboring rooms. Thus, a lot of markers are ruled out before the recognition process.

However, the marker re-usage leaves one question open: How does the application determine the initial room, where the user starts the application? For this purpose, we created an extra set of markers - the unique marker set. In every room, one marker of these unique markers is placed and assigned to that room. As a result, the application can determine the initial room immediately after recognizing the room's unique marker - all the user has to do is just to turn around 360 degrees once.

Testing & Future Work

The current model used for development and testing purposes covers parts of two adjacent floors in our institute building. The floorplan file holds geometry and adjacency information for 22 rooms. A total amount of 40 markers was used. Initial experiences showed that the system is heavily relaying on sufficient marker density. Whenever markers are too far away (or too small) much jitter is perceived by the wireframe model. Note, that the wireframe model can be turned off by the user, and the jitter does have nearly no impact on the direction arrows that are displayed to the user, because they still point to the next portal the user is meant to go to. It can be expected, that the jitter is reduced with a larger marker density. Gaps, which sometimes occur between markers, are mostly bypassed by using the inertial tracker. Unfortunately, the inertial tracker sometimes starts to drift in one direction leading the user to bear away from his path. Heading to a wall and viewing a marker from a close position adjusts the path shown on the users' view to the correct path again.

We found, that the degree of correct marker recognition relies heavily on the light conditions in the rooms. ARToolkit provides a useful feature to address this problem: One can assign a threshold to marker recognition, which influences the lightness at which a marker is recognized properly. However, in our application we are confronted with varying light conditions from one room to another or even in a single room.
We plan to implement adaptable thresholds, which allow to assign each room its own threshold for marker recognition according to its prior-known lighting.
Also, the quality of the tracking system could be improved by using Kalman filters to predict the user's motion.

We want to extend our digitized map to all floors of our building, as a more complete model would of course allow more comprehensive location based services. For this amount of digitalization professional grade surveying equipment will be necessary, but we think the result will justify the effort. The setup is suitable for outdoor scenes as well, and we intend to try this soon.

Material

Video

The demonstration video shows a user, who is guided by SignPost from the Virtual Reality Lab on 4th floor of IMS institute to the library on 5th floor. You can download the video from here:

Windows Media format (wmv)
Quicktime format (mov)
DivX video format (avi)

17.5 MB
22.8 MB
25.9 MB
640x480
320x240
720x576
25 fps
12.5 fps
25 fps
video length 3:30 min
video length 3:30 min
video length 4:08 min

Paper

SignPost and the marker re-use scheme were presented at ART02 - the First IEEE International Augmented Reality Toolkit Workshop. The publication 'Structured Visual Markers for Indoor Pathfinding' is available from here:

Online slides

Slides of a presentation of an early version of SignPost can be viewed here:

Credits

The SignPost application, the MapViewer tool, the ART02 paper, the SignPost and 'Structured Visual Markers for Indoor Pathfinding' presentations and this Webpage ...

... were developed, written & produced by these people:
  • Michael Kalkusch
  • Thomas Lidy
  • Michael Knapp
  • Gerhard Reitmayr
  • Hannes Kaufmann
  • Dieter Schmalstieg
 
Michael Knapp, Thomas Lidy, Michael Kalkusch
  Webmaster studierstube.icg.tu-graz.ac.at