LidarMultiStatic1

This simulation configuration requires use of the DIRSIG5-specific JSIM file, which allos the user to directly configure the plugins used in the simulation. This is required in order to run this multi-static collection as a single simulation because three instances of the BasicPlatform plugin are required (one for the transmitter and one for each receiver). The DIRSIG4-era XML .sim file support in DIRSIG5 is there for backwards compatibility, and it will only create a single instance of the BasicPlatform plugin.

The contents of the demo.jsim file are shown below, showing how to request and configure multiple plugins:

After the scene list is the plugin list for the simulation. The first plugin is an instance of the BasicAtmosphere plugin, which provides backward compatibility with DIRSIG4 atm configurations. In this case, the simple.atm file configures a classic DIRSIG4-era "simple" atmosphere.

The remaining three plugins are all instances of the BasicPlatform plugin, each with a slightly different set of input files. They are all part of a common collection, so they all use the same demo.tasks file. This task file contains a single, zero duration task that results in a single pulse being fired and received.

The remaining sensor plugin files will be discussed separately in the sections below:

The transmitter system is described in the tx.platform file. Note that this platform only contains a transmitter instrument. This platform file could be created with the graphical Platform Editor by adding a "bi-static source instrument" to the platform. The transmitter instrument related portion of this file is shown below:

Note that the clock for the transmitter is specified as 2000 Hz (or 2 kHz) with a 0 absolute time offset. When working with a multi-static system, the use of independent clocks with coordinated rates and offsets is important to synchronizing the various transmitter and receiver instruments.

The second component of the transmitter vehicle is the platform motion file. The tx.ppd file, which places the vehicle directly over the scene ENU origin at 2000 m (location is 0,0,2000). The rotation angles are all 0, which results in the system shooting pulses straight down.

Although there are two receiver platforms in this simulation, there is only one receiver platform file (see rx.platform). This platform file could be created in the graphical Platform Editor by adding a "bi-static receiver instrument" to the platform. Inspection of this platfrom will reveal that is contains a single focal plane instrument with the appropriate range gate for the expected time of flight based on the collection geometry. It is important to note that the clock for the receiver instrument is 2000 Hz with an absolute offset of 0 seconds, which identical to the transmitter. The use of matched clocks tied to the same absolute time offset is how this multi-static collection system is synchronized.

The use of a single platform file for both receiver instruments is not a requirement as each receiver can have a unique configuration. Instead this approach was chosen to show how one or more perfect clones of platform can be created and used in a simulation. Reviewing the JSIM file, you will see that each receiver vehicle (the two instances of the BasicPlatform plugin using the rx.platform file) has a unique platform motion file. This is what creates the multi-static collection geometry. The two receiver instruments are looking at the target area from the same altitude (2000 m) but from a 45 degree off-nadir direction. The first vehicle is offset 2000 meters to the south (-2000 Y in Scene ENU, as specified in the rx1.ppd file) and the second vehicle is offset 200 meters to the east (+2000 in X in Scene ENU, as specified in the rx2.ppd file). Each PPD file has the appropriate orientation rotation to point the receiver vehicle toward the target area at the scene origin (0,0,0).

Since the same platform file is being used for both receiver vehicles, the output files generated by both vehicles will be written to the same file (in this case, demo.bin). Instead, we want to separate the output from each receiver vehicle. This could be accomplished by making copies of the rx.platform file and changing the names of the output files. However, one of the goals of this demo was to show how the receiver instrument could be cloned by using the exact same rx.platform file. To avoid each receiver from writing to the same demo.bin file (which would result in each instance clobbering the output of the other), the BasicPlatform plugin supports "output folder" and "output prefix" options via the JSIM description. These options are the same as the command-line --output_folder and --output_prefix options, but more importantly the JSIM mechanism lets you specify these for each plugin instance. In this case, the output prefix for the first and second receivers are rx1_ and rx2_, respectively, which will result in the final files produced by the simulation being rx1_demo.bin and rx2_demo.bin.

It should be noted that the primary reason the same platform file can be used for both receivers in this scenario is because the time of flight is the same to both receivers. Although each receiver is positioned in a different location and at a different orientation, the time of flight for both is the same. If each receiver is going to have a unique time of flight, then the a unique platform file with the corresponding listening window (range gate) would need to be created.

To run the simulation, perform the following steps:

The second component of any DIRSIG lidar simulation is running the radiometric product through the detection model to generate time of flight (ToF) triggers, and then convert those triggers into a 3D point cloud. There are two aspects of this demo that are unique compared to most of the other DIRSIG lidar demos:

The simple_processor already supports the ingestion of multiple BIN files and will produce a single point cloud that merges the points generated by each receiver. Using this approach means that the characteristics of each receiver will be identical. If you want each receiver to have unique detection properties (detector characteristics, knowledge errors, etc.) then you would need to process each BIN file separately and provide the appropriate receiver parameters for each.

A typical mono-static system or even a bi-static system on the same vehicle can generally make the assumption that the range to the scene element that reflected (scattered) the transmitted pulse back to the receiver can be found by assuming it was half way through the total time of flight. This is because the time of flight from the transmitter to the scene is assumed to be the same as the time of flight from the scene to the receiver. However, for this scenario the receiver is off-axis from the transmitted (45-degrees), which makes the relative Tx/Rx path ratio 1/sqrt(2). This asymmetric Tx and Rx path time of flight scenario means that assuming the reflection (scattering) event occured half way along the total path is wrong. We cannot ask photons where they have been and how long they took to go there, so addressing this asymmetry involves supplying additional knowledge. The simple_processor has an option called --rx_path_fraction that allows the user to specify the fraction of the total time of flight that corresponds to the path from the reflection (scattering) event to the receiver. The default is 0.5 (mono-satic symmetry assumption). For this collection scenario both receivers see a total path that would nominally include the 2,000.0 meters from the transmitter to the scene and then 2,828.4 meters from the scene to the transmitter. That results in receiver path fraction being 0.5857.

The command line below shows how to run the detection model on both receiver BIN files using an ideal GmAPD system (unity photon detection efficiency (PDF) and zero dark count rate (DCR)) with the computed recieve path fraction and producing a single LAS with the points from both receivers merged: