NovAtel's Annual Journal of GNSS Technology Solutions and Innovation

Issue link:

Contents of this Issue


Page 19 of 51

Little Bird Evolution of a 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 frst — and simplest — technique was to generate an independent single-point differenced solution. Because the INS essentially provides a fltered 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 flter of the second body was then updated with the single-point position plus the relative vector of the frst body. This provided a means to "tie" the two systems together, relatively but very accurately. The third technique was a combination of the frst two cases. If the INS solution is a "smoother" version of the GNSS solution, then 20 velocity 2013 why not update the second body with the INS position plus the relative vector of the frst. 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 frmware had to be modifed for the completion of this application. A PowerPC board was developed to take on the task of running all the INS-specifc fltering 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 flter running on the SPAN board. Furthermore, adding an OEMV3 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 flter. Figure 1 shows the outline of the data fow for the overall system. The INS solution, computed by the flter running on the SPAN board, is 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. For more Solutions visit http:/ /

Articles in this issue

Links on this page

view archives of Velocity - 2013