User Tools

Site Tools


Processing a Revolution Trajectory

Revolution has several means by which a final trajectory can be computed. The base version of Revolution uses the VectorNav VN-300 INS which uses a GPS L1-only receiver with SBAS. See the VN-300 specifications here. It is important to note here that being an L1-only receiver does not mean it is a low quality receiver but that it is definitely not an L1/L2 survey grade receiver.

As an L1-only receiver the expected positioning can be upwards of 2 to 2.5 meters in XY. Often times this is roughly 50 cm in areas with a clear sky view. In Z the value can be twice that of XY. Clearly this is not survey grade. However, there are many applications for which this is just fine as the relative accuracy of the cloud over short distances (50 meters) remains quite reliable if no sudden changes in speed or direction occur.

In general, you can assume the quality of the trajectory goes from the simplest, easiest, least reliable to the most reliable as shown here:

  1. L1 only SBAS. 1 to 2 meters.
  2. L1 post process GNSS. 20 to 50 centimeters.
  3. L1 post process INS. 20 to 50 centimeters.
  4. L1/L2 RTK. 2 to 4 centimeters.
  5. L1/L2 post process GNSS.
  6. L1/L2 post process INS.

Using control points properly distributed and in sufficient number and quality, can make all of these solutions be of almost equal quality.

SBAS (real-time) Processing

In the base model the processing proceeds the same with or without SBAS. The INS file will generally be found in a Snoopy folder with the extension of *.gps. When you select the project folder (one folder above Snoopy) the software will automatically search for an existing INS file. It will find the *.gps file and begin processing it. If the project spans hours of collection this process could take a couple of minutes. In the end a trajectory will be generated in UTM meters on the ellipsoid.

At this point processing the point cloud proceeds identically to the standard method of processing unless the user wants to improve the trajectory by some other means defined below. See here for more details on how to immediately begin creating the point cloud.

Coordinate Update (CUPDT)

Revolution has a very nice feature (which is shared with all ScanLook systems). It can use an externally generated coordinate update file to correct the trajectory. This means that the L1-only derived Revolution trajectory can easily be updated to an L1/L2 survey grade trajectory. For users who already own higher accuracy GPS equipment this means they can re-use it to their advantage!!! This is quite a big deal. As long as the equipment can create a file with the appropriate format it is easy to correct the initial trajectory.

The Coordinate Update File (CUPDT) must be of the following format:

EventId gpsTime gpsWeek X Y Z Quality

The data needs to be entered time sequential and the higher the frequency the better the end result.

This may be best understood by using an example. Assume Revolution is mounted on a car and that the user owns an L1/L2 GPS unit that can record at 1Hz. This unit can be mounted rigidly to the scanner platform with measured offset values (the closer the better). The GPS must log data prior to scanning and after as well to be useful. The data can be RTK or post processed. The important thing is to mount it rigid relative to the scanner, measure the offset values, and create a coordinate update file.

Once this file is available it can be entered, along with the lever arms to the external receiver, on the CUPDT command on the main processing dialog. When the point cloud generation process is started, the trajectory will be form fit to the CUPDT file and then the point cloud will be generated.

Here's a sample.

Project:     Flight21
Program:     Inertial Explorer Version 8.60.6717
Profile:     UTM (meters) (GPS_only)
Source:      GNSS/INS Epochs(GNSS Combined)
ProcessInfo: Run (3) by Unknown on 09/02/2016 at 16:43:38
Datum:       WGS84, (conversion NAD83(2011) to WGS84 (850))
Master 1:    Name Homebase, Status ENABLED
           Antenna height 0.000 m, to ARP [NOV702GG_1.03(NONE)]
           Position 34 27 36.12394, -86 49 27.60809, 185.306 m (NAD83(2011), Ellipsoidal hgt)
           Position 34 27 36.14792, -86 49 27.63756, 183.995 m (WGS84, Ellipsoidal hgt)
Remote:      Antenna height 0.000 m, to ARP [Generic(NONE)]
Map projection Info:
  UTM Zone:    16
SD Scaling Settings:
  Position: 1.0000
  Velocity: 1.0000
  Attitude: 1.0000
SeqNum               GPSTime Week      Easting     Northing H-Ell Q SDHoriz SDHeight
                     (sec) week          (m)          (m) (m)  (m) (m)
0               508045.20000 1912   516115.086  3813189.627 177.997 1 0.014 0.027
1               508045.40000 1912   516115.089  3813189.628 177.995 1 0.012 0.024
2               508045.60000 1912   516115.088  3813189.628 177.996 1 0.011 0.023
3               508045.80000 1912   516115.087  3813189.629 177.992 1 0.011 0.022

All of the header information will simply be skipped until it reaches the line containing 0 508045.2.

L1 Post Processing

As of August 10, 2016, the RINEX file generated by the VectorNav receiver remains unavailable. However, it is quite possible to use a RINEX file from an external L1-only receiver mounted with the system.

During collection all of the orientation data is stored at 100Hz or more. Along with this data the RINEX data from the GNSS receiver is also stored. These two files can be used in additional software to compute a better trajectory. This can be done in two ways described below as Position Only and Position and Orientation.

L1/L2 Real-Time Processing

It is possible to use an L1/L2 GPS RTK system for revised trajectory calculations. In this case the RTK receiver will record data at least at 1Hz as described in the CUPDT section. The resulting RTK coordinates will then be used to correct the trajectory while the angles will remain unchanged. This makes very good re-use of existing GPS equipment. It is also a very good means of generating immediate results in the field for those time critical projects.

This method suffers from completely independent solutions of the orientation and position - there is no coupling at all. In post processing the solutions can be coupled giving the best solution.

L1/L2 Post Processing

Using a high quality L1/L2 GNSS receiver (with GPS + GLONASS, etc.) and storing a RINEX file for post processing will definitely yield the best results. This can be done in two ways described below as Position Only and Position and Orientation with the latter being the best solution.

Position Only

Using just the RINEX data, along with suitable base station data, the trajectory can be processed through a number of software packages available, such as RTKLib or NovAtel/Waypoint GrafNav. Once a revised trajectory is computed a CUPDT file can be created and used as described above (the lever arms would be all 0's if using the VectorNav RINEX file).

Position and Orientation

For those seeking a better solution, the orientation data is collected during data capture as a NovAtel IMR file and can be used with the RINEX file within NovAtel Inertial Explorer. Care must be taken to use the appropriate parameters during processing at this point as IE is very sensitive to each IMU's settings. Once IE is finished, processing can be performed the same as for any other ScanLook system. See here for more details on how to immediately begin creating the point cloud.

This solution has the full advantage of IE including a large variety of coordinate systems, loosely and tightly coupled processing, and multi-pass forward/reverse smoothing.

revolution-trajectory.txt · Last modified: 2016/09/02 18:03 by jeff.fagerman