|
| [+QUICK
INFO+] |
 |
| TEAM
: |
|
Human
Machine Interaction (HMI) group.
Robert Bosch Corporation - RTC |
| POSITION
: |
|
Software
Engineer Intern - Research |
| NOTE: |
|
I
can't really go into details about my research
at Robert Bosch Corporation - RTC due to security
reasons with sensitive materials, but here is
an overview of the whole system, as described
in the conference paper by Bosch.
Title: "Vehicle Navigation using 3D Visualization." |
| |
|
|
|
| [+OVERVIEW+] |
| Humans
grow up in a three dimensional world and this we have
a life-long experience interpreting and seeing the
perspective projections of the 3D world. The
traditional display mode for the task of navigation
and trip planning nowadays are generally in two dimensional.
In the research work I worked in at Robert Bosch Corporation
over the summer, they advocate the use of 3D techniques
for realistic representations of geographic data (maps,
roads, landscape, etc). Usually, most information
on a 2D map are displayed at a single scale and therefore
needs constant 'zooming-in' and 'zooming-out' of the
map to be able to get an overall view of the whole
area. In the process of creating a system capable
of managing geoinformation in an efficient manner
to offer 3D visualization for nagivation system, two
major parts are required. The offline and
the online parts of the nagivation system.
|
| [+OFFLINE
DATA PREPARATION+] |
Before
geo resources can be accessed at real-time on the online
system core, they need to be prepared in an offline
process. Huge data set of geo information need to be
partitioned and indexed in an efficient data structure
so that the online system can be possible. The units
that are going to be used to break the system down into
are going to be called tiles and the hierachical
structure to be used is going to be a tiling scheme.
In the field of image processing, many different techniques
have been explored over the years to partition and organize
such huge data set. The most common ones are Quadtree,
BSP tree and Octree. In this system, a Quadtree is going
to be used to store the tiles, which are set at fixed
tile sizes. In the offline process, the handling of
aerial photographs is the most important one and therefore
needs to be done efficiently. Generally, we're talking
in the range of TeraBytes for example for the region
of California at 1 m resolution. However, most application
will typically have as little as 500 MB available for
resource management.
The image data (satellite or aerial images) are required
for multiple resolutions for different parts of the
world. The most universal input format, that providers
all over the world offer, is image data rectified to
the WGS84 (World Geodetic System 1984) ellipsoid, the
geodetic reference also used in GPS systems. The corresponding
projection is UTM (Universal Transverse Mercator). For
exchange formats, compression standards like JPEG has
been used. From the image data collected, a multiresolution
pyramid that corresponds to a certain range of resolutions
will be created. The tiles created are all 256 x 256
pixels and are organized into 4 quadrants, with each
child splitting the parent node in 4 ways. The area
of a node can be specified in latitude and longitude,
and for instance the root node is at, N = 180 degrees,
S = -180 degrees, E = 180 degrees and W = -180 degrees.
The tiling scheme fixes the possible resolutions of
the pyramid.
Different fixed levels of resolution at zero degree
latitude, the corresponding approximate pixel width,
and the region size for tiles of 256 x 256 pixels.
| Level
# |
Tile Width |
Pixel Width
[m/pixel] |
Region |
| 0 |
360 |
156250 |
Earth |
| 1 |
180 |
78125 |
|
| 2 |
90 |
39062 |
Continent |
| 3 |
45 |
19531 |
USA |
| : |
: |
: |
|
| 8 |
1.41 |
610 |
Bay Area |
| 9 |
0.70 |
305 |
|
| 10 |
0.35 |
153 |
Silicon Valley |
| : |
: |
: |
|
| 15 |
0.0110 |
4.77 |
|
| 16 |
0.005 |
2.38 |
|
| 17 |
0.003 |
1.19 |
Block |
Each pyramid is a completely encapsulated structure
on its own. For generating a pyramid, each usually very
large input image for a specific resolution level n
is decomposed into lists of samples containing the sample's
colors Red, Green,
and Blue. The
advantage of this composition into sample lists is that
several input images can be combined into a single pyramid
without taking care of the projection. the image boundaries,
the color space, or the actual source resolution. For
the generation of the tiles, from the existing tiles
at resolution level n, the lower resolution levels are
constructed by downfiltering the now regular grids.
The tile at the next lower level is constructed by the
tiles at the four child nodes. Again, to avoid boundary
effects the surrounding 12 tiles can also be taken into
account. After filling the pyramid bottom-up, the next
step is to compress the tiles. The currently employed
coding scheme is JPEG due to its simplicity in terms
of computational complexity. |
[+SOFTWARE
STRUCTURE+]
|
| The
second part of the navigation system is the online system.
The latter is entirely written in Java and perform real-time
with 3D rendering and fast image retrieval. The core
of the visualization software is the Scenegraph Manager
which manages a scenegraph. A scenegraph is a data structure
which holds all data currently visible on the screen.
The Scenegraph Manager periodically purges old data
and requests new data (as the viewpoint changes) for
the scenegraph from the Resource Manager, which provides
access to one or more geo-databases. The system block
diagram of the 3D navigation system is as follows: |
 |
| The viewport
manager maintains a viewpoint, which specifies the location
from which the scene is viewed, as well as the direction
in which it is viewed. The viewpoint may move in one
of the pre defined viewpoint motions, for example, by
following a car, or in response to a user input. Finally,
rendered scenes may be retrieved from the rendering
engine and displayed on the navigation device. |
| [+MY
CONTRIBUTION+] |
Summer
2004
As a summer software engineering intern in the Human
Machine Interaction (HMI) group, I researched means
of optimizing the compression ratio of the multiresolution
pyramids. The visual quality of the generated tiles
is evaluated versus the rate of distortion in the compressed
images. From there different results have been analyzed.
This allowed for a better selection of a low-pass filter
for downsampling purposes, and also offered new capabilities
at compressing the overall data at a more efficient
rate. Different ways of arranging the data set were
explored again in the hope of optimizing compression.
|
|
|
Summer
2005
Worked on implementing a
distributed system of computers to generate multiresolution
pyramids in parallel. The resulting software improved
time consumption in the generation of those TeraBytes
pyramids in a considerable amount. In short, there
was a main server side which analyzed the job to
be processed, and partitioned it into sub-jobs
and scheduled their processes on a network of computers.
This improvement and efficiency of the distributed
system were proportional to the number of computers
available for processing on the network. At the
same time, I was working on developing new tools
for the current existing library that was created
for this project. At the end of the summer, the
project was a success with a reduction in processing
time from 3 weeks to 2 days. Project was shipped
to Germany for further testing. |
|
