Relative Navigation Solution

The initial development of “moving baseline” technology began in late 2004 and had the following requirements.

  1. High update rate (i.e., 100 hertz) for position and attitude
  2. Attitude accuracy of both vehicles to ±1 degree
  3. Capability of providing continuous position data of the touch down point (TDP) on the vessel when the TDP is not collocated with the navigation system's GNSS antenna or IMU.
  4. Relative position accuracy of 0.5 metres at 1 sigma.

Several methods were explored during this development. The first - and simplest - technique was to generate an independent single-point differenced solution. Because the INS essentially provides a filtered output of the GNSS solution, the relative accuracies between two INS solutions should be lower than that of two GNSS solutions.

The second method eliminated the static base station requirement and solved for the offset vector between the two moving antennas using typical double-difference techniques. The INS filter of the second body was then updated with the single-point position plus the relative vector of the first body. This provided a means to “tie” the two systems together, relatively but very accurately.

The third technique was a combination of the first two cases. If the INS solution is a “smoother” version of the GNSS solution, then why not update the second body with the INS position plus the relative vector of the first.

Finally, during the development and testing of these methods it was observed that the relative errors in the position between epochs were highly correlated. Therefore, a method was developed for computing a post-update correction to be applied directly to the output of the two integrated navigation systems. This correction varied slowly thus allowing it to be applied during the intervals in between the low rate RTK solutions.

Jump ahead eight years: the Little Bird project had received some funding and was getting ready for another test. NovAtel had to bring the “moving baseline” up to date in order to work with the newer hardware (SPAN-SE).

The unique construction of the SPANSE meant that two sets of firmware had to be modified for the completion of this application. A PowerPC board was developed to take on the task of running all the INS-specific filtering and functionality. This freed up the OEMV-3 processor to handle only the GNSS portion of the overall system: including the relatively low rate, onehertz, position updates used by the INS filter running on the SPN board.

Furthermore, adding an OEMV-3 can provide the capability of generating ALIGN heading updates from a single enclosure. This heading solution can also be passed back to the internal SPAN board via designated serial ports to allow for further updates to the INS filter.

Figure 1 shows the outline of the data flow for the overall system.

Figure 1

The local INS solution, computed by the filter running on the SPAN board, is repackaged in to an external  data packet. The data packet is then transmitted to the OEMV-3, where it is used by the various tasks depending on whether the SPAN-SE is currently operating as a Master or Remote. A matcher task is used to handle all of the RTK functionality needed to derive the carrier phase relative positioning and repackage the solution into another external message to be transmitted back to the local SPAN board for further processing and output. The relative solution with respect to the local station is available from either the master or the remote. For example, the relative solution output from the remote station will be the opposite of that same solution output at the master station.

As one can see, the major complication of this project was simply coordinating and matching the myriad of required data between not only the two external systems but also the subsystems inherent to the SPAN-SE design itself.

In order to account for the usersupplied eccentric offset, the master SPAN-SE was set up to transmit the INS position at the antenna as well as the position, velocity, and attitude corrected to the eccentric offset.

Figure 2

The underlying algorithms are quite simple and are based on two well-known techniques. First, computation of the RTK vector using double-differenced carrier phase observations and least-squares ambiguity decorrelation adjustment (LAMBDA), the well-documented method for the integer estimation of ambiguities proposed by Professor Peter Teunissen of Delft University, and second, fusion of GNSS/INS using an extended Kalman filter to control the INS errors via GNSS observables. The RTK translation vector is applied to the filtered master INS estimate and used as a noise-reduced position update to control the remote INS errors. Because the transfer system of the Kalman filter is governed by the input variance, was increased the covariance of the position update by a factor of three to help ensure that computed gains were properly distributed.

So, a position update at the remote receiver's location, where RP/MP is Remote Position and Master Position, respectively, has these elements:

Update = MPins + RTK Vector


Update Covariance = 3.0*MPins Covariance

If the RTK vector is not available, the remote will continue to perform local position updates using the single point least-squares position update and associated covariance.

Inertial errors at both remote and master vehicles typically vary slowly, which means the relative error between the two systems is also slowly varying.

With the presence of a valid RTK vector, the relative INS position can be corrected by differencing the two post-update INS positions from the RTK vector. This in turn will provide information about the amount of drift that has been experienced between the two INS systems. The correction can then be applied directly back to the post-update remote INS position.

It should be emphasized that the corrections are applied to the output of the inertial system, and not to the inertial system parameters themselves, as it will cause all the other inertial system components to become unobservable.

So, the steps in applying a remote relative position correction, are as follows:

Correction = RTK - (RPins - MPins)


RPcor = RPins + Correction


Relative Position = RPcor - MPins

The correction is used to remove the bulk of the relative error caused by the slowly varying wander noticed between the two INS systems. It will typically be updated at the requested rate, but will continue to be used for a period of up to five seconds.

After five seconds the amount of potential error in the correction could be as much as the singlepoint relative error; so, it will no longer provide any additional benefit and could actually begin corrupting the solution further.