Trajectory Report

The LiDARMill Trajectory Report is intended for data processors to glean insight pertaining to Navlab pipeline processing configuration details and kinematic navigation data specifications. The trajectory report focuses on assessing the quality of the resulting NavLab post processed trajectory.

Overview

Trajectory Processing Methodology

The Kalman filter produces estimates of the state of a dynamic system from a series of measurements and is used extensively in kinematic positioning and navigation for GNSS/INS (Inertial Navigation System) integration. Navlab utilizes the Kalman filter to perform forward and reverse trajectory processing using both the loosely coupled (LC) and the tightly coupled (TC) processing methods.

The LC method is a two-stage processing method where an inertial trajectory (IMU data) is processed in the forward direction and the reverse direction with updates from a previously processed GNSS trajectory. The TC method is also a two-stage processing method, however it processes GNSS and INS data simultaneously, which is typically the preferred method for computing GNSS + inertial datasets. Navlab processes a TC trajectory in the forward and reverse direction three times, compared to a LC solution's single pass.

Navlab also combines processing directions and performs back smoothing on the LC and TC solutions, which greatly improves position quality over GNSS data gaps. Even when there are no GNSS gaps present, smoothing will always generate the highest quality trajectory possible. A ".cts" output file is a combined and smoothed TC solution, whereas a ".cls" file is a combined and smoothed LC solution.

For best possible results, a trajectory is computed within each Navlab pipeline multiple times using different processing methods and vehicle dynamics profiles, in order to derive the highest quality trajectory output.

Dynamics Model

The NavLab pipeline scans the unprocessed position records from the ".nav" file in order to determine if the dynamics are characteristic of aerial, ground vehicle, etc. “Automatic” is selected by default within Navlab, which automatically detects the best dynamics model for processing.

4 Character Trajectory Solution Description

Example: 1TAV

Character 1: The number represents how many reference stations were used for processing the solution

Character 2: Letter represents the type of trajectory solution - T = TC , L = LC

Character 3: Letter represents the dynamics profile used - U = UAV, A = Airborne, and G = Ground Vehicle

Character 4: Letter represents either Enable or Disable Doppler - O = disable the use of doppler for velocity determination , V = enable the use of doppler for velocity determination

Overview

Data Acquisition Time

Local and UTC date and time of mission

Output Datum

Output datum of post processed trajectory

Input Raw Data

File name of input ".nav" raw trajectory file containing IMU and GNSS information from rover's mission

Output Processed Trajectory

File name of highest quality trajectory produced from Navlab pipeline processing. File name is "(nav File name)-(Output datum)-(4 character trajectory solution description).(cts or cls)"

Solution

Description of processing methodology used to derive highest quality trajectory solution

Reference Station Configuration

Inputting the correct reference station position is a very important step in trajectory post processing. Select from the available post processed positions in the drop down menu, or enter your own "Custom" position if you positioned your reference station over a known ground point.

Note:

Custom reference station positions generally reference a survey marker on the ground. In this case, input the known X,Y, and Z coordinates, measured height to ARP, and antenna model. This will ensure the phase center, or applied antenna height is properly computed and used during PPK processing.

Alternatively, when a LiDARMill derived OPUS or RTX solution is selected, the coordinates are already at the phase center elevation (measured antenna height is 0 and antenna model is marked as "generic" in order to avoid incorrectly applying a phase center offset)

Reference Station "Reference station file name"

Reference Station File

Uploaded static reference station file name

Reference Station Input

Position type (OPUS, RTX, PPP, AVERAGE or CUSTOM)

Antenna Model

GNSS reference station antenna model

Measured Antenna Height

Input height of reference station antenna, measured to specified “Measured To” point

ARP to L1 Offset

Vertical offset from Antenna Reference Point to L1 phase center offset. Measurement corresponds to Antenna Model.

Applied Antenna Height

L1 phase center height

Measured To

Measurement mark for reference station antenna height (L1 phase center or (ARP) Antenna Reference Point)

Geographic Coordinates

Geographic latitude and longitude reference station coordinates (DDMMSS.SSSS)

Grid Coordinates

Grid coordinates expressed in Easting (X), Northing (Y), and Ellipsoidal Height along with Grid type and Zone

Input Datum

Datum of input reference station coordinates

Epoch

Reference station datum epoch

Rover Configuration

During rover configuration in Navlab, it is required to specify whether the lever arm Z value is measured to the antenna’s reference point (ARP) or L1 phase center. When ARP is specified as the antenna height reference point, the correct rover antenna model must be specified. In doing so, the antenna model’s phase center offset value is applied to the Z value to raise the Z value to the L1 phase center.

Rover Configuration

Antenna Model

Applies the phase center offset associated with the selected antenna model. “Generic” is selected by default, meaning the lever arm is measured to the antenna phase center already.

Measured To

Reference point where the lever arm is measured. Use “L1 phase center” if lever arm is measured to phase center, but use “Antenna Reference Point” if lever arm is measured to bottom of the antenna mount (be sure to select antenna name in this case).

Lever Arm Offset (IMU to GNSS Antenna #)

To perform GNSS updates accurately, enter the 3-D offset, in meters, from the IMU sensor array’s navigation center to the GNSS antenna. This offset vector must be entered with respect to the body-frame of the vehicle (X right, Y forward, Z up).

Body to IMU Rotation (Order: Z, X, Y)

Some IMUs are installed in a tilted and/or rotated position with respect to the body frame of the vehicle. If the tilt/rotation between the IMU frame and body frame is known, Navlab compensates so that the attitude information produced is with respect to vehicle body frame, not the IMU sensor frame. The order of rotations employed is Rz, then Rx, followed by Ry, in decimal degree units.

QA/QC Plots

The following plots are utilized to assess the quality of the post processed trajectory

File Data Coverage Plots

This series of plots shows data coverage as a function of time (X axis = GPS seconds of week) for camera triggers, reference station GNSS observations, rover GNSS observations, and rover IMU data. This plot is useful in determining whether any base station data does not fully overlap the rover data time interval.

Forward/Reverse Attitude Separation Plot

This plot shows the difference between the forward and reverse solutions in terms of roll, pitch and heading as a function of time. A zero separation is ideal, as it indicates matching solutions in the forward and reverse IMU processing. Spikes at the beginning and the end of the plot are common, as they indicate the periods of alignment. As a rule of thumb, a quality trajectory has a forward/reverse attitude separation < +/- 2 arcmins.

Forward/Reverse Positional Separation Plot

The following plot shows the north, east and height position difference between the forward and reverse solutions. Plotting the difference between forward and reverse solutions can be an effective QC tool. When processing both directions, no information is shared between forward and reverse processing. Thus both directions are processed independently. When forward and reverse solutions agree closely, it helps provide confidence in the solution. To a lesser extent, this plot can also help gauge solution accuracy. However, if there is a common bias in both forward and reverse solutions (for example, due to inaccurate base station coordinates or due to a large residual tropospheric error), it will never be seen in the combined separation plot. Large differences in the combined separation plot may be a result of different solution types (fixed/float) or different levels of float solution convergence between the processing directions and thus not a direct indication of a problem. It is important to also consider solution status (fixed/float plot below) when evaluating forward/reverse differences. As a rule of thumb, a quality trajectory has a forward/reverse positional separation <+/- 0.02 meters in Easting, Northing, and Up.

Height Plot

The following plot shows the ellipsoidal height of the rover as a function of time.

Velocity Plot

The following plot shows rover velocity as a function of time in north, east, up and horizontal directions.

Acceleration Plot

The following plot shows rover acceleration as a function of time in the north, east and up direction.

Rover GNSS Satellite Count

The following plot shows the number of satellites used in the solution as a function of time. The number of GPS satellites, GLONASS satellites, and the total number of satellites are plotted by color.

Float or Fixed Ambiguity

The following plot indicates where the processed solution is fixed (in one or both directions) or float. If both forward and reverse solutions achieved a fix, the plot shows a value of 2 and is plotted in bright green. If either the forward or reverse achieved a fix, but not both, a value of 1 is plotted. The value will be plotted cyan if the fixed direction is forward and blue if the fixed direction is reverse. If neither direction achieved a fix, a value of 0 is plotted which appears red on the plot. This plot can be helpful to view in conjunction with the Combined Separation plot, as it will help determine if large values in the forward/ reverse separation are expected or not, depending on solution status in each direction.

IMU to GNSS Lever Arm QA/QC

The X, Y and Z IMU to GNSS lever arm states are added to Navlab's kalman filter. After processing, the best converged estimate (forward direction, reverse direction, and averaged) of the lever arm is reported in the table below labeled "Computed for Analysis 4th iteration Results" with the averaged 4th iteration lever arm values differenced from the input lever arm values.

Navlab automatically computes 4 iterations and the resulting lever arm measurement convergence is plotted below, with the X axis showing iteration number, and the Y axis showing lever arm offsets colored by X,Y,Z lever arm calculations (Forward direction on the left, Reverse on the right). Note that Navlab's ability to estimate lever arm values is dependent on the quality of the inital lever arm measurement input, correct vehicle body rotation, the amount of data collected and vehicle dynamics."

User Input

Lever Arm Offset (IMU to GNSS Antenna)

Input lever arm X offset measurement (used in trajectory post processing)

Input lever arm Y offset measurement (used in trajectory post processing)

Z (to phase center)

Input lever arm Z offset measurement (used in trajectory post processing)