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