Processing block

Description

The processing block is used to configure how Qinertia should process the mission. You can select the processing mode, the motion profile dynamics and even select which GNSS base stations should be used in the solution.

Processing modes

Qinertia offers several processing modes from GNSS only PPK (Post Processed Kinematic) to fully automated tightly coupled INS solution. Qinertia also features different GNSS augmentation algorithms from single base station to Virtual Base Station (VBS) network to deliver a centimer-level accuracy in all situations.

Auto/Manual modes

Qinertia CLI has been designed from the ground up to offer a unique and advanced automatic processing mode. In this mode, Qinertia picks up the best processing algorithm based on available base stations and mission profile. However, Qinertia CLI also gives a full manual control on how the processing is done to address all our integrator needs:

Manual mode: In manual mode, you have a full control and you explicitly tell Qinertia to process the data using a dedicated processing algorithm. If the selected processing mode requires GNSS base station data, you are responsible to tell Qinertia which base station has to be used. You can however ask Qinertia to download base station data from a CORS network and/or import your own base stations data.
Automatic mode: Qinertia comes with a powerful automatic processing mode that tries to pickup the best GNSS augmentation solution based on the mission data and available base stations. This automatic processing mode first download all surrounding base stations. Then, it combines the downloaded base stations with the ones optionally imported by the user to select the best available GNSS processing mode in that order of preference:
1. Single base Station PPK
2. Virtual Base Station PPK
3. Post Processed PPP (Precise Point Positioning)

Processing Types

The table below list all available processing modes that can be selected depending on your Qinertia license:

Mode	Description
`gnssAuto`	Automatic GNSS only processing: Process RAW GNSS data to output a GNSS only post processed solution but let Qinertia select the best algorithm according to available base station and mission data.
`gnssSingle`	Single base station GNSS only processing: Explicitly ask Qinertia to process RAW GNSS data to compute a GNSS only PPK solution using a single base station. The processing will fail if no valid suitable GNSS base station has been specified in the Base Station Block.
`gnssVBS`	VBS GNSS only processing: Explicitly ask Qinertia to process RAW GNSS data to compute a GNSS only PPK solution using a Virtual Base Station. The VBS is created using the bases stations specified in the Base Station Block array. The processing will fail if the specified base stations are not suitable to create a valid VBS network.
`gnssPPP`	PPP GNSS only processing: Explicitly ask Qinertia to process RAW GNSS data to compute a post processed Precise Point Positioning solution. The PPP solution is available worldwide but it offers a lower accuracy and longer convergence time than other processing modes.
`insAuto`	Automatic INS processing: Process RAW GNSS and IMU data to compute a tightly coupled INS solution but let Qinertia select the best algorithm according to available base station and mission data.
`insSingle`	Single base station INS processing: Explicitly ask Qinertia to process RAW GNSS and IMU data to compute a tightly coupled INS solution using a single base station. The processing will fail if no valid suitable GNSS base station has been specified in the Base Station Block.
`insVBS`	VBS INS processing: Explicitly ask Qinertia to process RAW GNSS and IMU data to compute a tightly coupled INS solution using a Virtual Base Station. The VBS is created using the bases stations specified in the Base Station Block array. The processing will fail if the specified base stations are not suitable to create a valid VBS network.
`insPPP`	PPP INS processing: Explicitly ask Qinertia to process RAW GNSS and IMU data to compute a post processed Precise Point Positioning INS solution. The PPP solution is available worldwide but it offers a lower accuracy and longer convergence time than other processing modes.
`insLoosely`	INS loosely coupled processing: The mode uses PVT (Position Velocity Time) measurements that are, most of the time, real time GNSS solutions to compute a post processed loosely coupled INS solution. The processing will fail if no valid PVT data has been imported.
`insReprocess`	INS reprocessing: Compute an INS solution in forward only direction using PVT measurements. This processing mode should return the same results as a real time INS solution. The processing will fail if no valid PVT data has been imported.

GNSS Base Stations

The processing block contains a bases parameter that is an array of Base Station Block entries. This array lets you import GNSS base station data and also list the base stations to use in the solution.

This bases parameter has different usage scenarios depending on the selected processing mode as shown below:

Automatic: The parameter is optional and can be used to add user base stations in addition to the ones automatically downloaded by Qinertia. All these base stations will be taken into account by Qinertia to pick up the best GNSS algorithm.
Single Base: The parameter is required to specify the base station to use in the PPK solution. The array should contain only one base station otherwise the processing will fail.
Virtual Base Station: The parameter is required to specify a list of base stations to use in the VBS network. At least three bases stations are needed to successfully create a VBS network.
Precise Point Positioning: The parameter is ignored as PPP doesn't use base station data at all.
INS loosely or reprocessing: The parameter is ignored as INS loosely/reprocessing uses PVT data directly.

Qinertia is fully integrated with CORS (Continuously Operating Reference Stations) network and can download, for you, base stations data from several CORS providers. It can also use base stations imported by the user and even combine both downloaded and user base stations.

To support this feature, the Base Station Block can be used in two different ways:

If you specify GNSS base station data files, Qinertia will import this base station.
lf you don't specify data file but just a base station name, it will force Qinertia to download this base station and use it.

JSON Block Sample

INS automatic mode

The example below uses the automatic mode to let Qinertia pickup up the best GNSS augmentation solution. Qinertia will download automatically all needed resources for you.

"processing": {
  "motionProfile": "automotive",
  "type": "insAuto"
}

JS

Single Base Station (User defined frame)

The processing block below illustrate an INS tightly coupled solution using a user supplied Emlid Reach RS2 base station. The base station position is read from the base station file but the frame (datum) is supplied by the user.

"processing": {
  "motionProfile": "uav",
  "type": "insSingle",
  "processFrom": "2020-04-27T09:00:00Z",
  "processUntil": "2020-04-27T09:15:00Z",
  "singlePass": true,
  "bases": [
    {
      "positionMode": "published",
      "position": {
        "frame": "RGF93"
      },
      "data": [
        "base/emlid-reach-rs2.ubx"
      ]
    }
  ]
}

JS

Single Base Station (PPP survey)

The processing block below illustrate an INS tightly coupled solution using a user supplied base station. The base station position is not known precisely so the user ask Qinertia to compute a PPP static solution before starting the INS processing.

"processing": {
  "motionProfile": "marineHarshSurvey",
  "type": "insSingle",
  "processFrom": "2020-04-27T09:00:00Z",
  "processUntil": "2020-04-27T09:15:00Z",
  "singlePass": true,
  "bases": [
    {
      "positionMode": "ppp",
      "data": [
        "base/30232770.16g",
        "base/30232770.16n",
        "base/30232770.16o",
        "base/30232780.16g",
        "base/30232780.16n",
        "base/30232780.16o",
        "base/30232790.16g",
        "base/30232790.16n",
        "base/30232790.16o"
      ]
    }
  ]
}

JS

Virtual Base Station

In this example, we will ask Qinertia to download six bases stations from IGNRGP CORS network and combine these base stations with one user supplied base station to create a VBS network.

"processing": {
  "motionProfile": "uav",
  "type": "insVBS",
  "bases": [
    {
      "name": "DOMP",     
    },
    {
      "name": "SEES"
    },
    {
      "name": "MAUP",
    },
    {
      "name": "BRMZ",
    },
    {
      "name": "MAN2",
    },
    {
      "name": "COVI",
    },
    {
      "positionMode": "manual",
      "position": {
        "latitude": 48.018614136,
        "longitude": 0.155282549,
        "height": 128.174,
        "frame": "RGF93"
      },
      "data": [
        "base/41232770.16g",
        "base/41232770.16n",
        "base/41232770.16o",
        "base/41232780.16g",
        "base/41232780.16n",
        "base/41232780.16o",
        "base/41232790.16g",
        "base/41232790.16n",
        "base/41232790.16o"
      ]
    }
  ]
}

JS

Manual Rejections

You can create manual areas where INS aiding such as GNSS position are rejected forcing pure inertial position. This feature is reserved for advanced users for troubleshooting and setup validations. It should not be used in normal production environment as Qinertia embeds advanced filters to automatically reject aiding when necessary.

Please find below a simple example that reject GNSS position and velocity measurements as well as true heading information for 200 seconds.

"processing": {
  "motionProfile": "automotive",
  "type": "insAuto",
  "rejection": {
    "begin": "2022-12-25T09:02:00Z",
    "end": "2022-12-25T09:05:20Z",
    "useAidings": {
      "pvt": "never",
      "hdt": "never"
    }
  }
}

JS

Create Project From CLI file

You can create project in Qinertia from a full or partial CLI file. This is very helpful to both offer a nice third party IMU support with project settings reading like feature as well as to debug your CLI files.

The following example, shows the only parameter that is read and used when you create a project from a CLI file in Qinertia GUI.

"processing": {
  "motionProfile": "marine"
}

JS

Block Specification

Parameter	Type	Description
`motionProfile`	enum	Select the motion profile / vehicle dynamics to use for the processing: `airplane`: Airborne vehicles that have a likely forward travel direction `automotive`: Ground vehicles such as cars with low to no side slip `helicopter`: Rotary wing vehicles that don't have a specific travel direction `marine`: Marine applications such as bathymetry and vessel monitoring & control `marineHarshSurvey`: Dedicated to high performance bathymetry in high multi-path environment `pedestrian`: Used for very low velocity applications that have no likely forward travel direction `truck`: Ground vehicles such as trucs or cars with steered rear axle that experience minor slide slip `uav`: Designed for highly accurate surveys with UAV (fixed or rotary wings) `static`: Assumes static GNSS RAW observables to improve accuracy (GNSS only).
`type`	enum	Select the processing mode such as GNSS only or INS tightly coupled solution: `gnssAuto`: Automatic GNSS only processing `gnssSingle`: Single base station GNSS only processing `gnssVBS`: VBS GNSS only processing `gnssPPP`: PPP GNSS only processing `insAuto`: Automatic INS tightly coupled processing `insSingle`: Single base station INS tightly coupled processing `insVBS`: VBS INS tightly coupled processing `insPPP`: PPP INS processing `insLoosely`: INS loosely coupled processing (uses PVT) `insReprocess`: INS reprocessing (uses PVT)
`mechanicalEstimationPass`	bool	Set to `true` to estimate mechanical installation parameters and then automatically execute a second run to get the final post process solution. Only the parameters that have been flagged to be not precise in the Settings block are estimated.
`processFrom`	string	ISO 8601 UTC date time which specify from which point in time we should process data.
`processUntil`	string	ISO 8601 UTC date time which specify until which point in time we should process data.
`singlePass`	bool	If set to true, force Qinertia to process the log only using one passe instead of the default three passes.
`bases`	array	Array of GNSS base stations to use and import in the processing. See below for object details. The parameter can be required or optional according to the selected processing mode: Required for: `gnssSingle`, `gnssVBS`, `insSingle`, `insVBS` Optional for: `gnssAuto`, `insAuto` Ignored for: `gnssPPP`, `insPPP`, `insLoosely`, `insReprocess`
`rejection`	array	Optional list of rejections areas to forbid the INS to use some aiding such as a GNSS position, true heading, odometer velocity and so on. Please check the rejection object definition below.

Base station sub block

Parameter	Type	Description
`name`	string	Base station name that is required to explicitly tell Qinertia to download and use a base station from a CORS network. In this case you should NOT specify any data files. Otherwise, if you have specified data files, this optional parameter can be used to override the base station name read from the files.
`receiver`	enum	Manually specify the base station GNSS receiver model so Qinertia can tune its GNSS algorithms to deliver optimal results. The available GNSS receiver models are: `auto`: Try to detect the model from imported data or fallback to `default` `default`: Use this model if your GNSS receiver is not listed `ubloxF9`: L1/L2 u-blox RTK receiver with RAW data `septentrio`: Survey grade Septentrio receivers `novatel`: Survey grade Novatel receivers `trimble`: Survey grade Trimble GNSS receivers `javad`: Survey grade JAVAD receivers `ashtech`: Survey grade Trimble/Astech receivers `topcon`: Survey grade Topcon receivers `spectra`: Survey grade Spectra receivers `leica`: Survey grade Leica receivers If not specified, the receiver model is detected automatically. If the model can't be detected or is not found the `default` model is used.
`positionMode`	enum	Define which position Qinertia should use for this base station: `auto`: Let Qinertia select the best available base station position between PPP and the published one. `manual`: The base station position is read from the position.x parameters of this block. `ppp`: Automatically compute a static PPP on the base station data and use this position. `published`: Use the position from the CORS provider database or from the the RINEX / base station file. If you don't specify this parameter, Qinertia will use the `auto` default mode.
`position.latitude`	number	Base station latitude in decimal degrees and positive north. Required if `positionMode` is set to `manual`.
`position.longitude`	number	Base station longitude in decimal degree and positive east. Required if `positionMode` is set to `manual`.
`position.height`	number	Base station height above ellipsoid in meters and positive upward. Required if `positionMode` is set to `manual`.
`position.frame`	string	Base station position frame name. Optional for `auto` and `published` modes. Required if `positionMode` is set to `manual`.
`antenna.type`	string	Antenna ANTEX identifier that can ovverides the one read from the GNSS data. The valid options are: `auto`: to let Qinertia detect the antenna from the input GNSS data and fallback to generic if not antenna model is found `generic`: to use a default antenna model that doesn't apply any APC/ARP or L1/L2 offset `custom`: to specify your own L1/L2 ARP to APC offsets. In this case, the offsets node is mandatory. any valid ANTEX id such as `"TWIVSP6037L NONE"` for example If not specified, the default `auto` option is selected.
`antenna.offset.l1`	number	Define the ARP to L1 phase center vertical offset in centimeter for GPS signals. This field is applicable and mandatory only if `antenna.type` is set to `custom` value.
`antenna.offset.l2`	number	Define the ARP to L2 phase center vertical offset in centimeter for GPS signals. This field is applicable and mandatory only if `antenna.type` is set to `custom` value.
`antenna.height`	number	Antenna height offset in meters to apply between the base position and the selected reference point (APC or ARP).
`antenna.reference`	enum	Choose where the base station position is referenced to: `arp`: The position is referenced to the Antenna Reference Point (default). `apc`: The position is referenced to the Antenna Phase Center point.
`data`	array	List of GNSS data files to import for this base station. The paths can be either relative or absolutes. If you don't specify data files but just the base station name, Qinertia will download the base station data automatically from CORS databases.

Relative Paths

Relative paths are referenced to the JSON process file unless you have specified a base path with the --input option while invoking Qinertia command line.

Rejection sub block

Defines a single rejection entry with a being/end epoch time. You can create as many rejections as you would like but they should not overlap.

For each rejection entry, you can define for each aiding input if it should be rejected or not from the INS solution. For example, you can decide to only reject the GNSS true heading but still use the GNSS position.

At least one useAidings item should be specified such as all or pvt.

Parameter	Type	Description
`begin`	string	ISO 8601 UTC date time when the rejection area starts.
`end`	string	ISO 8601 UTC date time when the rejection area ends.
`useAidings.all`	string	The `useAidings.all` property is exclusive with other specific aiding below. Use the `"never"` value to reject all aiding inputs.
`useAidings.pvt`	string	Set to `"never"` value to reject GNSS position and velocity data. GNSS position and velocity measurements are only used in loosely coupling or reprocessing modes. This rejection has no effect for tightly coupled modes and you should rather use `gnssRaw` aiding to forbid GNSS usage in the INS solution.
`useAidings.gnssRaw`	string	Set to `"never"` value to reject RAW GNSS aiding for tightly coupling processing modes.
`useAidings.hdt`	string	Set to `"never"` value to reject dual antenna GNSS true heading measurements.
`useAidings.dvl`	string	Set to `"never"` value to reject Doppler Velocity Log aiding.
`useAidings.odo`	string	Set to `"never"` value to reject Odometer (DMI) wheel speed aiding.

GNSS only processing

Rejections are only relevant for INS processing modes and have no effect for GNSS only processing.

Download PDF