Keywords: lidar
Summary
This demonstrates a side-looking LIDAR system looking at a far off object. It also outlines the use of the Advanced GmAPD model to produce ASCII/Text Level-0 (time-of-flight) style data.
Details
This demo models a LIDAR system with a simple transmitter and a 32 x 32 receiver array with 2 us long listening window and 1 ns time resolution (resulting in 2001 time bins) looking at a spherical object that is 90 nautical miles away. The collection is then run through the Advanced Geiger-mode APD (GmAPD) detector model to produce ASCII/Text Level-0 (XYT) and Level-1 (XYZ) point clouds.
Important Files
This section highlights key files important to the simulation.
Geometry and Materials
The scene is comprised of a single sphere that is 5 meters in diameter
(2.5 meter radius) and is defined in demo.glist
. The sphere is placed
166.680 km (90 nautical miles) away.
<geometrylist> <object> <basegeometry> <sphere> <matid>1</matid> <radius>2.5</radius> <center><point><x>0.0</x><y>166680</y><z>10.0</z></point></center> </sphere> </basegeometry> <staticinstance/> </object> </geometrylist>
The reflectance property for the sphere is a spectrally flat 10% Lambertian
(see materials/demo.mat
and the optical property files in the materials
folder).
Platform
This section summarizes the properties of the transmitter and receiver components of the laser radar system used in this demo.
The following are the characteristics of the transmitter:
Pulse wavelength: 1064 microns Pulse repetition rate (PRF): 20,000 Hz Pulse length: 1 ns Pulse energy: 1 mJ Beam divergence: 0.05 mrad
The following are the characteristics of the receiver:
Focal length: 8 m Aperture diameter: 10 cm Array size: 32 x 32 elements @ 50 micron pitch Range gate width: 2 us Range gate resolution: 1 ns Range gate bin count: 2001
The 0.05 mrad beam divergence results in a beam that is approximately 16.7 meters across at the 168.8 km range. The projected focal plane is similarly 16.7 meters across at this range (the radial beam under filling the corners of the focal plane some). Since the sphere is only 5 meters across (2.5 meter radius), it only fills a fraction of the focal plane (about 20 pixels out of the 4096 pixels in the array). Although modeled as a co-bored system, the optical coupling/throughput of the optical system is set to 50% in an attempt to account for reflection and transmission losses of the optical elements in both the transmit and receive paths.
The platform is located at 0,0,0 in the Scene ENU coordinate system. The LIDAR system is rotated 90 degrees about the Scene ENU X-axis to point toward the sphere target down the Scene ENU Y-axis.
Radiometry Options
This simulation uses the Direct+PM (photon mapping) approach. That means that direct returns are analytically computed using radiometric equations. Higher order bounces are computed using photon mapping, where photon "bundles" are launched from the transmitter, bounce around the scene and record bounce events in a 3D map with arrival times. The photon mapping setup uses 250,000 bundles shot from the transmitter and stores 100,000 bundle events in the map.
Setup
Run the Radiometry Simulation
To run the simulation, perform the following steps:
-
Run the DIRSIG
single.sim
file to generate a single pulse, or -
Run the DIRSIG
multiple.sim
file to generate 100 pulses.
Both simulations output to the demo.bin
file.
Expected Run-Time
The multiple.sim
simulation takes about 1m40s on a 2014 quad-core 2.8 GHz
Intel i7 laptop. Remember that since DIRSIG4 is not multi-threaded, the
number of cores is irrelevant.
Photon Map Usage
It is important to note some details in the DIRSIG radiometric simulation output:
Attempting to fill LASER surface map ... Shooting laser source: 0.0% full done. Number of photon bundles shot = 250000 (250000 allowed)
The output indicates that photon mapping algorithm is shooting the maximum
number of photon bundles from the transmitter (250000
) and the photon
map does not accumulate any events (0.0%
). This is actually expected
since the map does not store any primary (directly reflected) events
in Direct+PM mode and the sphere scatters all the photon bundles away.
receiver. A more complex object at this range would accumulate more
events in the map as 2nd, 3rd, etc. bounces interact with the object
rather than being scattered away.
BIN File Analysis
It is always useful to verify the link budget (the number of photons arriving onto the pixels during a pulse). The BIN Analysis tool can be used to examine and summarize the radiometric values and supporting metadata in a BIN file. This tool can be run via the Analyze button in the detector model interface or via the command-line:
$ bin_analyze demo.bin ... [header summaries deleted for documentation purposes] ... Pulse #1: Minimum total photons in a pixel = 2.5478e-17 Maximum total photons in a pixel = 0.220529 Pixels with zero total photons = 0/1024 (0%) Average background photons per pixel = 3.10288e-06 Average total photons per pixel = 0.00263392 Complete!
Since the sphere object does not fill the focal plane, the maximum total number of photons in a given pixel is of greatest interest because the average includes a large number of pixels that have very little return. It tells us that the maximum link budget is 0.22 average photons/pulse (presumably from the retro-reflection in the center of the sphere).
To better visualize what the radiometric returns look like, the
bin_analyze
tool can also be used to extract spatially summed and
temporally summed products for each pulse. This is performed using the
command-line options --output_grids=true
and --output_profiles=true
.
For example:
$ bin_analyze --output_grids=true --output_profiles=true demo.bin
This will produce a pair of files for each pulse in the input BIN file:
-
The
profile_0.txt
file contains the spatially average temporal waveform (the average number of photons vs. time across all pixels). -
The
pulse_0.txt
file contains the temporally summed photons for each pixel in the receiver array.
This two files are plotted and shown below:

profile_0.txt
file showing the returns arriving near the center of the range gate.
pulse_0.txt
file showing the total number of photons reflected by the sphere object.The higher photon count pixels in the center of the focal plane indicate the returns from the sphere. Recall that the beam width is the same as the focal plane width, but there is nothing to reflect the beam back to the receiver beside the sphere
If the bin_analysis
tool is run on a multi-pulse BIN file then a separate
file for each pulse is generated with the pulse index X
encoded into the
output filenames as profile_X.txt
and/or pulse_X.txt
file. More info
about the bin_analyze
tool can be found in the Lidar Modality Handbook.
Geiger-mode (Gm) Detector Modeling
Converting the spatial x spatial x time photon arrivals into triggers is handled by the Advanced GmAPD Detector Model. This section outlines the GmAPD device description and using the detector model to produce both Level-0 and Level-1 data.
GmAPD Device Description
The Geiger-mode detector model simulation uses detector specifications commonly found on Princeton Lightwave’s commercial Geiger-mode array devices:
-
Photon detection efficiency (PDE) of 0.5
-
Dark count rate (DCR) of 5 kHz
-
Published 32 x 32 array cross-talk (which can be found in
$DIRSIG_HOME/lib/data/gmapd
).
These device characteristics are captured in the demo.gmapd
file included
in this demo.
Generating Level-0 Output
To confirm the existence and structure of our sphere object, the detector model was run with "ideal" array characteristics by enabling the following options on the Detector Array tab in the interface:
-
Override photon detection efficiency (use ideal instead)
-
Disable dark count fires
-
Disable early fires
-
Disable cross talk fires
-
Disable background (passive) flux
The Advanced GmAPD Detector Model has the option to produce ASCII/Text Level-0 data, which is simply time-of-flight data. Each GmAPD trigger event is represented as a triplet containing the X, Y and time index. In this demo we have a 32 x 32 pixel array and a 2001 bin range gate, so the L0 data for every pulse will contain triplet indices in those respective ranges. The ASCII/Text L0 data can be plotted as either 2D data (collapsing the XY spatial dimensions) or 3D data. In addition, the ASCII/Text Level-0 output can optionally contain header/comment lines that break the triggers into chucks by pulse (see example below):
# Generated by the DIRSIG Lidar Detector Model # DIRSIG Release: 4.7.4 (r17345) # Build Date: Sep 14 2017 12:31:23 # # Column/Field Summary: # PulseIndex, X, Y, T # Pulse #0, relative time = 0 15, 14, 981 15, 16, 979 15, 17, 983 # Pulse #1, relative time = 0 14, 15, 984 15, 15, 978 # Pulse #2 16, 18, 988 # Pulse #3, relative time = 0 16, 14, 981 15, 15, 979 16, 16, 979 ... # Pulse #99, relative time = 0.00495005 14, 15, 982
This ad-hoc ASCII/Text format was created due to the lack of an established and/or community accepted Level-0 format. It does not contain all the meta-data required for translating it into Level-1 data. However, it is suitable for testing algorithms that would operate on Level-0 data directly.
The plot below shows the L0 data plotted as XY vs. Time. Using these ideal detector settings the only triggers will be from the sphere object, which can be observed in the center of the plot. Due to the link budget, the detector does not fire for every pixel containing target. The output L0 data contains approximately 250 fires, or about 2 fires/pulse even though there are at least 20 pixels/pulse overlapping the target. The spread of the points in the vertical (spatial) axis is due to the spatial extent of the object it the plane of the beam. The spread of the points in the horizontal (time) axis is due to returns from the different ranges to the sphere (due to the curvature) that are imaged.

Running the detector model with those options disabled yields a more realistic result. The output L0 data file now contains nearly 1,700 fires or about 17 fires/pulse. The cluster of points related to the target can still be observed in the center of the plot. The additional fires are dark count related fires, including cross-talk fires initiated by dark count fires.

Generating Level-1 Output
Level-1 (unfiltered geo-located point cloud) data output can be generated by simply changing the output type in the Output tab of the interface.