I posted a quick Yaftie (our sensor fusion demo platform) update earlier this week, mentioning that we are implementing RTK (Real-time kinematic positioning) using LoRa as a communications method (more on why LoRa in a future post), and I thought it might be worth talking a little about what RTK is and why it is needed.
A bit of history…
Back in the ‘80s, when the first commercial GPS devices started to become available, GPS was limited in its accuracy due to something called Selective Availability (SA). This was how the U.S. military could ensure that potential adversaries would not benefit from precise positioning. SA deliberately degraded the L1 frequency being transmitted by the satellites, which would cause the calculations being completed by the receiver to be calculated at random error of up to 100m. This meant that civilian GPS was limited to an accuracy of 100m, which is a far cry from the approximate 5m accuracy that can be achieved today, since SA was abolished in 2000, and with modern multi-constellation receivers.
To improve the accuracy of GPS, a technology called Differential GPS (DGPS) was established that would allow a GPS receiver to correct its calculations with correction data sent by land-based transmitters. This was achieved by a fixed station knowing its exact location and time, and since it would also be seeing the 100m error, it could transmit the correction values to any local DGPS receivers that were using the same satellites. Adding in data from other sources of errors, such as those caused by atmospheric conditions, clock drift, and known ephemeris data, the accuracy of a GPS receiver using DGPS data could be improved to around 5m.
The first systems were developed and installed by the US Coast Guard to help with maritime navigation around ports and some inland waterways, transmitting their correction data over marine longwave frequencies that could be received using existing radio sets and fed into a GPS receiver. Most of the major GPS manufacturers could ingest this signal, whether from the maritime signal or from air band VHF or other radio bands.
During the ‘90s, DGPS and other variants were rolled out around the world, improving GPS accuracy to a point that SA was no longer having the intended effect of disrupting commercial navigation accuracy. This was one of the reasons that SA was switched off in 2000.
Once SA was no longer active, the best DGPS systems could achieve an accuracy of up to 10cm. DGPS had got to a point where, even with SA, a system using one of the DGPS systems could achieve a higher accuracy than a standalone receiver with SA disabled.
With the advent of multiple GNSS constellations coming online, improvements in receivers, and the fact that a lot of the existing DGPS infrastructure is now reaching the end of life, traditional DGPS has fallen out of favour. For most users, a good multi-constellation, multi-band receiver is accurate enough.
So, RTK?
RTK is basically just a massive improvement on what traditional DGPS could achieve.
RTK improves on DGPS by using carrier phase measurements, multi-band (L1/L5), and multiple constellations to correct its local position. A base-station sends this data to a receiver, or rover, in RTK speak, to correct its position. This can give <3cm accuracy, which is especially useful in use cases such as mapping, autonomous vehicles, surveying, and agriculture.
Photo by Elias Tsapaliaris {ilias_fly_zen} on Unsplash
In our RTK implementation, the data is conveyed to a rover using a protocol called RTCM. This can be sent over IP using a standard called Networked Transport of RTCM via Internet Protocol (NTRIP), which has been standardised by the Radio Technical Commission for Maritime Services (RTCMS). This is based on HTTP and requires an IP connection to a server. An NTRIP server (or caster) ideally needs to be sending RTCM data from a base station that is physically close to the rover. This is due to the rover needing to be able to see the same satellites that the base station is using; otherwise, the carrier calculations are not relevant to the rover. There are RTK services that you can subscribe to, which give you access to an NTRIP caster. The caster takes a rover’s location and then sends the corrections from the closest base station.
Photo by Elias Tsapaliaris {ilias_fly_zen} on Unsplash
For instances where there is no base station, or the power to run a bi-directional IP link can be spent, a local base station can be deployed. This is what we are currently implementing with Yaftie.
Yaftie RTK Implementation
Along with implementing support for NTRIP Casters (hopefully some exciting news coming and another future blog post!) we are also developing a standalone system that allows us to deploy a Yaftie board as a local RTK base station which then broadcasts the required RTCM data over a low power RF link to a Yaftie rover which selectively listens when it expects to be able to hear the base station.
The base station is told its exact position, and we then use this and data from the GNSS chipset to create the RTCM data to be sent to the rover.
The rover only listens when it thinks there should be RTCM data available, saving power, and then applies the correction data to improve accuracy.
Why?
So why are we doing this? Well, apart from being quite cool that we can get our location on Еarth from satellites down to a few cm precision, it does have real-world applications.
The first obvious use case is surveying and mapping, both of which often require precise location. To create accurate site surveys mapping where utilities, or where Earth works, require location data as accurately and quickly as possible. Doing this with RTK means that post-processing is cut down and multiple site beacons are not needed, cutting down costs and improving precision and efficiency.
Another upcoming use case is autonomous vehicles. By their nature of zipping around on their own, they need to know exactly where they are to help them navigate a chaotic world. Being able to pinpoint the location as precisely and quickly as possible helps the multitude of autonomous vehicles, such as drones, delivery robots, or cars, to avoid each other, and more importantly, avoid causing harm to living things.
As part of adding RTK to Yaftie we are planning a simple demo that shows how we can track a “delivery truck” (my car) around the country whilst on the open road using non RTK assisted GNSS where precision is not so important but then automatically switch to using RTK when arriving as a warehouse with multiple unloading bays (otherwise known as Roedan HQ, or office). This allows the delivery truck to be located down to the exact yard, and then the exact bay (car parking spot in the case of my car) that it is unloaded in. This, when combined with Yaftie-enabled forklift trucks, allows the yard to monitor the exact location of the incoming delivery vehicles and the onsite unloading forklifts to help streamline operations.
