852
The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences. Vol. XXXVII. Part B5. Beijing 2008
features for such an in-flight quality monitoring tool should be
the RT display of the scanning progress and the detection data
gaps within the flight.
outlined in the upper part of Figure 3. Practically, the timing
scale is governed by the 1PPS and the timing offset is
communicated between the modules via Ethernet.
1.2 Paper outline
We first present the strategy of merging the data streams from
different technologies (i.e. inertial navigation, GPS positioning,
laser range measurements) in real-time while performing all the
necessary computations for obtaining the georeferenced laser
point-cloud. Secondly, the core of the tool, the real-time
GPS/INS orientation estimate and the subsequent RT
georeferencing of the ALS data is presented in detail. Thirdly,
we describe the qualitative evaluation of the strip data and its
presentation to the system operator. Finally, we will present the
results of first experiences and demonstrate its application in
practice.
2. GENERAL SYSTEM ARCHITECTURE
Reaching in-flight data quality and coverage monitoring
capacity required adopting a particular strategy in data
processing and communication architecture that allows scalable
distribution of tasks across a network of computers. The setup
of data acquisition, synchronization and processing was guided
by the following goals:
• Achieve independence between ‘vital’ and ‘extended’
system functionality
• Achieve performance scalability
• Achieve centralized monitoring and control
The first goal assures that the ‘vital’ modules responsible for
data acquisition and synchronization cannot be disturbed by the
state or processing requirements of the other modules. The
second goal promises handling different scanning rates by
means of separating modules individually (or in groups) across
different computational platforms. Finally, the last goal
centralizes the management for the flight operator.
Software
*
LiDAR 4 Sync 1PPS IMU 4 Sync 1PPS GPS
IQ KHZ
400HZ
f Hz
i
▼
r
ALS
IMU
GPS
DATALOGGER
DATALOGGER
1 DATALOGGER
: ETHERNET <10OM&p*iS
LIEOS
\(RT point cloud ycotc let en cingi
Q
ìeora
pom
>
ÑT PosMfcm & Attitwkf
(400 Hz)
RT Swath
boundary (1 Hi) m
S' GHNAV
\^(Wr Kafman filter} y
<
LIAN
\ <
RT Rmttioet &
Attitude (1Hz)
{point cloud data anatyait)
}
1 Data E xtend
HELIPOS
am) gaps
(vactonzad)
► data quality monitoring
am/1fight management
4 RT*
Figure 3: Overall architecture of in-flight quality tool
As depicted in Figure 3, the LiDAR, the IMU and the GPS
receiver have each its data acquisition software module. These
modules can run on different processors if needed. Each module
is responsible for storing the data and for passing them together
with the status message to the connected clients. The control
module (called HELIPOS in Figure 3) runs as a separate
instance (usually on a different processor) and connects to all
data acquisition modules in order to monitor their performance
by means of status messages.
On the intermediate level there is firstly, the GPS/INS
integration module “GIINAV”, secondly the direct
georeferencing module (LIEOS) that embeds also the LiDAR
analyses module (LIAN). These modules run again as
independent instances that can be placed on different processors
if needed. GIINAV connects to GPS and IMU data sockets and
provides real-time GPS/INS navigation. Its position and
orientation output is further broadcasted to LIEOS where it is
merged with LiDAR raw measurements for
• real-time point-cloud generation within flight-line (see
section 4)
• detailed point-cloud analyses (see section 5)
The outer bounds of the real-time laser profile generated by
LIEOS are transmitted to HELIPOS that displays the scanning
progress in the background of the flight plan (see Figure 8).
HELIPOS can connect either to GIINAV for obtaining the
current position, velocity and orientation data or to GPS data
logger to obtain the receiver position and velocity from which
the system-heading is calculated. After completion of a scan
line LIEOS calls the LIAN module to perform statistical testing
on the obtained laser point-cloud and transmits this information
to HELIPOS for visualization.
In the sequel we describe the system architecture in more detail
from its intermediate level. Although we present a concrete
system, the same architecture can be applied to different
hardware by adapting only its bottom functionality, that is, the
modules responsible for data acquisition.
3. RT GPS/INS INTEGRATION
The data processing applications (GIINAV and LIEOS) benefit
from the same architecture. Both can be deployed either with
graphical (e.g. Figure 4) and/or only shell interface (e.g. Figure
5). Alternatively, they can run silently in the background until
receiving a termination message from the monitoring
application (i.e. HELIPOS). Both applications can also initiate
the bottom level programs from which they feed the data.
Finally, their input/output is handled entirely via sockets.
Therefore, they can be deployed across the network on different
processors, if the system specific computation load requires so.
The fundamental prerequisite for achieving these goals is in
establishing common and fast communication across all
hardware and software components. The Ethernet with TCP/IP
and UDP protocols has been chosen for this purpose. In the
particular case of our mapping system, the Ethernet
communication is already built-in in the LiDAR and IMU
modules (Skaloud and Viret, 2004), while the GPS receiver
needed to be interfaced to the network. The principles of the
data acquisition and synchronization for this specific system
were described in (Skaloud et al., 2006) and are schematically
The navigation module GIINAV is the real-time strapdown
inertial navigator and GPS/INS data integrator. The integration
is performed via loosely-coupled Extended Kalman Filter
(EKF) with 21 error-state vector (Tome et al., 2000). The
inertial data are processed in its original sampling (i.e. 400Hz in
the actual configuration of the Scan2map), while the GPS data
rate is typically set to one second. The critical part of the
integration algorithm is related to its orientation initialization, a
non-trivial issue especially for the helicopter-bom flights. For
that reason, the operator has the option to perform either