When it comes to accurately measuring position, different methods have different strengths and weaknesses. That’s why OxTS combine both inertial and GNSS measurements in our highly successful systems to create an accurate and reliable measurement platform. This dual-technology approach exploits the individual strengths of each technology and allows our users to continue taking measurements in environments that would normally make testing difficult.

There is however a third, and less well known layer of technology that can be applied to data measured by an OxTS RT, Survey+, Inertial+ or xNAV, further enhancing its accuracy in really challenging situations. It’s called combined or forwards/backwards processing and is applied during post-process. To understand how forwards/backwards processing works, it is necessary to recognise the strength and weakness of inertial and GNSS technologies, and why they provide such a strong solution when combined.

This is illustrated clearly in Figure 1, which shows the path measured by each technology as a vehicle passes through a long tunnel. As the vehicle enters the GNSS-blackout zone (black/yellow stripes), the signal is lost. Working from the left of the image:

Figure 1. Measured paths through a tunnel with different technologies

• Actual path: the red line indicates the path the vehicle took, including swerving to avoid an obstacle. This is the path we want to capture.
• GNSS-only path: the red line shows the path a GNSS receiver thinks the car took. The receiver loses GNSS lock as it enters the tunnel and re-acquires it shortly after exiting. While it is possible to “join the dots” and fill in the path, that isn’t an acceptable solution for most users as it completely misses the swerve manoeuvre.
• Inertial-only path: for illustrative purposes, an exaggerated constant drift has been applied to this path starting from the very top of the image. Notice how without GNSS correction, the position is already off at the tunnel entry compared to the actual path. While this trait is undesirable, the benefit is that the inertial sensor captures the lane-change manoeuvre dynamics exactly, but can’t be precise about the position because of the accumulating drift.
• Inertial+GNSS path: this is how your OxTS system sees things. It’s important to note the position is now correct as the vehicle enters the tunnel, because GNSS measurements prevent any drift occurring in the system. Crucially, this improves the position accuracy from the tunnel entrance to the swerve manoeuvre because there is less accrued drift. This is visible at the apex of the swerve even though the same exaggerated drift has been applied as the previous example. As the car leaves the tunnel and GNSS lock is acquired, the position accuracy of the system improves again and any accumulated drift is corrected. It is possible for your unit to snap back to the correct location on reacquisition, or to transition smoothly as shown here.

While a GNSS aided inertial solution is clearly the most desirable choice because it still captures activity in tunnels or areas of poor GNSS reception, it can be enhanced further still when used with forwards/backwards processing.  Remember, GNSS signals don’t need to be completely blocked for them to produce unreliable data.

In the previous example the data was considered in a forward direction—that means in the order it was received in real-time. Forwards/backwards processing works in the same way initially (the forward part), but because it is working in a post-process environment, there is the option to read the data backwards as well. From a GNSS-only point of view there is no benefit to backwards processing because nothing new can be learnt during the black-out period.

In the case of an inertial-only system, there is some benefit to running the data backwards because any drift error accumulates in a different way. Imagine a ship sailing in a crosswind. On the outward journey it sails straight, but is blown off-course and arrives to the left of its destination. On the return journey it again sails straight, but this time is blown to the right of its home port. Knowing this indicates the wind direction, which is analogous to drift in an inertial-only system.

Processing the inertial data from ends, using forwards/backwards processing, works in a similar way. Even though only one journey is made, it provides two different solutions to the same problem. These solutions can then be used to generate additional information about the system as a whole. Unlike the ship, which sailed from one known location to another, an inertial-only system doesn’t know exactly where it starts or finishes.

That’s why OxTS systems use both GNSS and inertial technology, so they do know exactly where they are. The points where the GNSS signal is lost and reacquired become the two known points the system moved between. And unlike the ship, the OxTS INS/GNSS has a highly-accurate inertial sensor inside to capture every movement made between those two points.

Figure 2. Calculated paths through a tunnel with different processing techniques

While forwards/backwards processing isn’t as simple as using one solution to cancel out the other, that is the underlying principal. It is illustrated in Figure 2, which shows the same scene as Figure 1 but from above. The red circles represent the point where the GNSS signal is lost and reacquired, and we’re interested in the area between those. Working down from the top:

• Forward processed inertial path: this is the same path labelled as “Inertial+GNSS” in Figure 1. It shows the path the OxTS system thinks it took based on the data it received in real-time, which is the same as forward processing. The absence of GNSS correction means drift (exaggerated for illustration) begins to accumulate in the system and when GNSS lock is achieved again, the system is not quite where it thinks it is.
• Backwards processed inertial path: in a real-time environment, the system uses inertial data to calculate the path it has taken. This is the forward processed path. In a post-process environment that same data can be fed to the system backwards from a good known location. In this case the known location is where a GNSS measurement was re-established at the tunnel exit. The post-process navigation system doesn’t know the data is being supplied in reverse order and simply computes a path based on the input measurements given. However, the algorithm responsible for sending the data in reverse order knows the calculated path should originate from the point GNSS measurements were re-established, and translates it to the correct position. This doesn’t stop the system from drifting in the absence of GNSS correction, but it does mean any drift accumulates at the opposite end of the path.
• Forwards/backwards paths overlaid: once a path has been calculated forwards from the point the GNSS signal was lost, and backwards from the point GNSS measurements were re-established, the two paths can be overlaid. In this way the best data from the forward path (white) and backward path (black) can be combined to form the forwards/backwards path (grey) that you can see overlaid with the real path the vehicle actually took.

It is worth noting we have only highlighted the benefits of forwards/backwards processing from a lateral perspective and under extreme conditions. The process however also applies in a 3D framework, and results in significant improvements in pitch, roll and yaw measurements too. While it is not necessary to utilise forwards/backwards processing during short periods of GNSS signal loss, it will still enhance data in the same way.

If you would like to know more about forwards/backwards processing, or any OxTS products or technologies, please contact OxTS directly or your regional dealer. Details can be found on our website: www.oxts.com.