= Applanix Processing (Manual) =

== Procedure ==

 1. Create new project, aim at <data dir>/applanix.  Name should be '''"YYYYJJJ.ppc"'''. Aim 'POS Data First' at applanix/Raw/ and select the first file.  Both filename kernels should be '''"YYYYJJJ"''' (YYYY = year, JJJ = Julian day (including flight letter)).
 1. Hit "Extract". If POSPac crashes, check first raw file contains data.
   1. Kernel should be '''"YYYYJJJ"'''.
   1. Read through output for errors - key things to look for are data gaps (if large, you may have to split the processing)
 1. Hit "POSGNSS" ** '''The POSGNSS stage does not need to be done if the ipas navigation has already been processed - see below''' **
   1. Convert input files to GPB (File -> Convert -> Raw GPS to GPB)
   1. Plane applanix
     1. Set receiver type to auto-detect
     1. Point at the applanix/Extract directory (check this!) and 'Auto add all' (this should add a !NovAtel OEM3 file)
     1. Select the Novatel file, click options and ''Make all epochs Kinematic'' (this is because the !NovAtel is the sensor on the plane, which is definitely kinematic!)
     1. Run the conversion (check output for errors)
   1. Base stations (repeat for all base stations - in the Rinex dir)
     1. Set receiver type to autodetect
     1. Point at the base station directory, probably Rinex, and 'Auto add all' (this should add a file, probably Rinex for the UK)
     1. Run the conversion (check output for errors, some health warnings are ok)
   1. ''File -> Add Remote File'', select the gpb file in the applanix/Extract directory, defaults fine
   1. (for all base stations - note: multiple base stations may need other stuff done)
     1. ''File -> Add Master File(s)'', select the gpb file in the basestation (Rinex) directory
     1. (if you have gaps, it may offer to resample for you - not sure if we need to do this or not)
     1. The basestation data will come with extra info specifying the precise location and antenna type.
     1. Fill in the antenna type (use advanced method) if you have the info, otherwise set the height appropriately
     1. The base station location will come in a particular datum/coordinate system - you '''must''' correctly convert this to a form that POSGPS knows about.
     1. For UK base stations, see the instructions below for this conversion.
   1. Load the airborne settings (''Settings -> Load Settings From -> Airborne'')
   1. Process differential (button looking like a blue world with a ruler on it).  This brings up a set of options.
     1. Change the ''Process -> Process Information -> Desc'' each run so you can compare between results.
     1. Try a run with the default settings first. 
     1. Read the output for hints as to problems.  You want to see "Fixed" ambiguity and a green (1).
     1. You will probably need to change the settings to improve the trajectory (and the below graphs) See [wiki:Processing/GrafNavProcessing/diffgnsssettings here] for things to try.
     1. Iterate as often as needed
   1. When processing is complete, the track will be coloured according to the quality of the data.  The important parts should be green!
   1. Click the graph button (or ''Output -> Plot GPS Data'') and review the error estimates.
     1. To get time periods for the important parts of the track, left click on points on the track and note the time.
     1. To restrict the display on a graph, right click on points to set start/end time or to restrict the Y range.
     1. Important statistics (remember these are just estimates and not based on ground truth!):
       1. Number of satellites (BAR)- needs to be 5+ for a chance of adequate data quality
       1. Combined separation - displays the difference between the forward and reverse solutions for each axis - want the error to be small (<10cm for X & Y, < 30cm for Z) and the separation tiny.
       1. (mggr needs to transcribe the rest from notes)
   1. When happy you have the best you can, click ''Output -> Export to !PosProc''.  Then save and exit POSGPS (goes back to POSPac)
 1. Run POSProc.
   1. Change the Proc. filename kernel to YYYYJJJ.
   1. Make sure "Post-Process GPS" is ticked - if it's not there, you didn't save the POSGPS output correctly!
   1. Click the Subsystem setup button and enter the reference -> IMU lever arm offsets from the table below. Note that the reference axes have positive Z DOWN and positive Y to starboard (numbers below are correct for this).
   1. Run the process - read the messages for errors again!
 1. You should now have a sbet file in .../Proc/sbet_YYYYJJJ.out - this is what's needed for processing
 1. Save project and exit POSPAC


To check on the right coordinates of OS active stations, see the link below 
http://gps.ordnancesurvey.co.uk/active.asp

Base station data not 1 second resolution?  Resample (interpolate using posgps).  While this doesn't improve the data, it apparently makes it more evenly applied (no internal interpolation?).  Unverified.

=== Exporting Grafnav Result to POSPAC ===

If you have already done navigation processing in grafnav you can export the results to POSPAC. This saves doing the GNSS processing two times (one for LiDAR IMU and one for Applanix IMU). The version of Grafnav is newer than the POSGNSS version and should be used instead of POSGNSS.

When the solution in Grafnav is ready to be exported, save the project and go into POSGNSS. Open the Grafnav project into POSGNSS, ignore warnings about being an older version. Then click the "combine GNSS" or "combine PPP" button. This will load in the previous solution. This can then be exported to POSProc as per usual.  If the "combine" buttons are not highlighted, then you can goto the menu and select combine solutions, select the files and load in the forward and reverse ones.


=== Optional extras ===

Output as ASCII - this isn't used for processing, but you might want to be able to look through the position estimates manually/programmatically. Note this is how you obtain external nav files for !CaliGeo.
 1. Hit Grid and ensure that all options (projection, UTM zone, etc) are appropriate for the dataset.
 2. Hit 'OUTPUT', hit 'ok' (or hit XYZ button)

View the trajectory

--------------

== Lever arm offsets ==

|| '''Year''' || '''X''' || '''Y''' || '''Z''' ||
|| 2006       || 1.068   || 0.182   || 1.489   ||
|| 2007       || Use 2006 :S || Use 2006 :S || Use 2006 :S ||
  
N.B. Some of the 2006, 2007 data has a preset IMU lever arm offset of `0.907, 0.190, 1.783` - not sure where this comes from, perhaps coords noted on the plane?  Dave Davis has said to use the `1.068, 0.182, 1.489` offsets.

---------------
== Basestation handling ==

=== Automatic basestations ===


Free basestation data (from Nico@Applanix): 
{{{
Coming to one data set: You may know that you can download base
station data from the IGS service. These stations are free of charge
and you can download them from inside of POSGNSS.

You should try to download free base stations from POSGNSS. The tool
can be found under >>Tools/Download service data<<.

Go to tab >>add closest<< and enter coordinates of interest and hit
>>find stations<<. Select the stations that are close enough.

Got to >>download<< tab and define the path, date, start time, length
of flight and interpolate to 1 second data. Then click download.
}}}

=== International base stations ===

Mostly the same as for UK - just make sure the position is correct and in the correct datum (may need transformation or conversion).

=== UK Rinex base stations ===

==== 2009 ====
Since moving to Smartnet, it appears the positioning information provided in the files is correct and doesn't need any conversion.  If your file extension is .09o you don't need to do anything else.

==== 2007/8/? ====
For the UK Rinex stations, the position is provided as Earth-centered Cartesian coordinates (XYZ) in the ETRS89 datum (directly compatible with WGS-84, just more exacting).  As they're compatible, these coordinates just need to be converted to WGS-84 lat/longs for POSGPS.  If we were coming from or going to a different datum/coordinate system (e.g. OS National Grid), we would need to do a coordinate transformation rather than conversion - this is complicated!

For the O/S UK GPS network (Rinex format files), the .07o file has a header like this:
{{{
     2.1            OBSERVATION DATA    G (GPS)             RINEX VERSION / TYPE
GPServer 2.50 2620  Rinex Merge         11-May-07 08:03:46  PGM / RUN BY / DATE
NEOT                                                        MARKER NAME
                                                            MARKER NUMBER
National GPS Network Ordnance Survey                        OBSERVER / AGENCY
0036227             LEICA SR530         4.20                REC # / TYPE / VERS
     0                                                      RCV CLOCK OFFS APPL
102098              LEIAT504        LEIS                    ANT # / TYPE
  3918702.4172    -7624.0107  5015612.3424                  APPROX POSITION XYZ
        0.0000        0.0000        0.0000                  ANTENNA: DELTA H/E/N
     1     1     0                                          WAVELENGTH FACT L1/2
     5    C1    P2    L1    L2    D1                        # / TYPES OF OBSERV
     1.000                                                  INTERVAL
  2007     5    10     9     0    0.0000000     GPS         TIME OF FIRST OBS
The APPROX POSITION XYZ coordinates are NOT APPROXIMATE     COMMENT
APPROX POSITION XYZ replaced by precise ETRS89 values       COMMENT
                                                            END OF HEADER
}}}

Note the `ANT # / TYPE` line and the `ANTENNA: DELTA H/E/N` for antenna details.

The `APPROX POSITION XYZ` is the precise ETRS89 X,Y,Z location (see COMMENT sections to confirm this it says it's precise).  This must be converted to a WGS-84 lat/long:
 1. Go to http://www.ordnancesurvey.co.uk/oswebsite/gps/information/coordinatesystemsinfo/gpsspreadsheet.html and get the coordinate conversion spreadsheet (or see attachment)
 1. Enter the coordinates from the `APPROX POSITION` field in the .07o file into the XYZ fields on the Enter Coords here sheet, clearing the other fields
 1. Check the constants are set for WGS-84
 1. Take the lat/long/ellipsoidal height from the ''XYZ to lat,long,H'' sheet and enter into POSGPS (you may want to save these as a favourite too)


-------------------------

== PPP Processing (when no base station data is available) ==

Follow the standard method to the point of adding the remote gpb file.

 * Settings -> Load Settings From -> Airborne PPP
 * Process -> Process PPP (single point)
   * Hit Precise tab. Ensure start and end dates entered are correctly and hit download. This will download precise clock and ephemeris files. Add these files when you are prompted.
   * Hit Process when you are happy with all other settings.

 * Check the quality of the data (especially the track colour (bright green is best) and 'Combined Separation' Plot). 
   * If the quality is not satisfactory, alter settings and reprocess. (Note: The reported quality of data using the PPP processing method does not seem to be consistently repeatable.  e.g. When processing the data with the same settings consecutively, the track colour and combined separation plot tend to vary). 

 * Follow standard processing method from exporting to !PosProc.

Note: If you get: "error: cannot find DCB epoch within <n> weeks of gps week <n>", the only way around this has appears to be using (the latest version of) grafnav instead of POSGNSS. After you get acceptable results you can then save as a PSGNSS project and carry on back in POSGNSS. 


Note from Nico on practicalities of PPP:
{{{
PPP might not be a good solution here. This method requires a long time of data
logging before the flight mission and afterwards. If I say long, I mean around
30 minutes.

This time is required before the algorithm can converge yielding a solution. So,
whenever you plan to use PPP in the future please make sure you log enough data
before you take off and after landing.
}}}
-------------
== Processing tips ==

If the data quality isn't good enough, then you can change some of the settings to effect improvements / admit more data.
 * cut out sections of the track if they have significant gaps
   * right click on the track and set start/end time in the appropriate places, then reprocess
 * lower the satellite horizon - you might do this to accept more satellite if there are an inadequate number covering an area (minimum 5 for decent quality)
 * increase KAR range - up this if your base station is further than 30km away
 * try different ionosphere models

-----------
Todo: add in detailed notes from Applanix training course