Skip to content
This repository has been archived by the owner on May 26, 2023. It is now read-only.

Introduction to RTK

David Smith edited this page Oct 25, 2020 · 1 revision

GPS Refresher

The distance between a satellite navigation receiver and a satellite can be calculated from the time it takes for a signal to travel from the satellite to the receiver. To calculate the delay, the receiver must align a pseudorandom binary sequence contained in the signal to an internally generated pseudorandom binary sequence. Since the satellite signal takes time to reach the receiver, the satellite's sequence is delayed in relation to the receiver's sequence. By increasingly delaying the receiver's sequence, the two sequences are eventually aligned.

The accuracy of the resulting range measurement is essentially a function of the ability of the receiver's electronics to accurately process signals from the satellite, and additional error sources such as non-mitigated ionospheric and tropospheric delays, multipath, satellite clock and ephemeris errors, etc.

Once all the range measurements are collected the GPS can then trilaterate its own position.

What is RTK?

Real-Time Kinematics is a technique used to improve the accuracy of satellite-based positioning (like GPS). It uses measurements of the phase of a signal's carrier wave in addition to the content of the signal (GPS data) in order make a positioning observation. In addition, the system relies on real-time corrections coming from a base station or an aggregate of base stations who also measure the phase of carrier wave signals. This allows the units to calculate their relative position to within millimeters, although their absolute position is accurate only to the same accuracy as the computed position of the base station. The typical nominal accuracy for these systems is 1 centimeter ± 2 parts-per-million (ppm) horizontally and 2 centimeters ± 2 ppm vertically.

The range to a satellite is essentially calculated by multiplying the carrier wavelength times the number of whole cycles between the satellite and the rover and adding the phase difference. Determining the number of cycles is non-trivial, since signals may be shifted in phase by one or more cycles. This results in an error equal to the error in the estimated number of cycles times the wavelength, which is 19 cm for the L1 signal. Solving this so-called integer ambiguity search problem results in centimeter precision. The error can be reduced with sophisticated statistical methods that compare the measurements from the coarse-acquisition (C/A) signals and by comparing the resulting ranges between multiple satellites.

How does MRover use RTK?

RTK Configuration

Our RTK configuration currently consists of one base station module and one rover module. The easiest way to remember our configuration is as follows, the base station rtk module will be located on the MRover base station and the rover rtk module will be located on the MRover rover.

Networking

The base station's RTCM corrections are sent over LCM to the rover where they are written over serial directly to the rover's gps module. The result being that if the base station is working correctly and you can communicate with the rover then the connection between the base station and rover gps modules has already been established.

Running our code

Note: If you are having trouble executing the code assume super user privileges by appending sudo to your ./jarvis exec commands.

Running the base station code

On the base station, the base_station/gps program should be run to interface with the base station gps module, the device file for the base station gps module may vary based on what devices are currently plugged in but it is expected to be a ttyACM device where a number starting from zero is appended to the device name to specify which device is which. Expect the base station gps filepath to be /dev/ttyACM0 and you should probably be fine. If you need to change the file path to the mounted device file you can do so by changing the config file located in config/gps/config.json. The relevant key to change is filename for the base_station object.

Running the rover code

On the rover, the jetson/gps program should be run to interface with the rover gps module, the device file for the rover gps module may vary based on the devices that are currently plugged in but will most likely be some variant of /dev/ttyACM. Expect the rover gps filepath to be /dev/ttyACM0 when running on the physical rover. If you are testing both the rover and base station gps modules connected to a single computer, then first plug in the base_station and then the rover, the rover gps module should be mounted to the device file /dev/ttyACM1. If you need to change the expected filepath you can do so on the config config/gps/config.json the object of interest is currently labeled onboard but may at some point be renamed to jetson. The relevant field is filename.

The Config

The config is located in config/gps and holds configuration information for both the base station and rover gps code.

Rover Config

Here is a breakdown of the config variables for the rover

baudrate: The baud rate the rover gps module is configured to communicate at over serial

filename: The path to the device file that the rover gps module is mounted to

max_error_count: The number of consecutive exceptions that can occur before the error is propagated forward and crashes the program

sleep: The amount of time in seconds that the gps code should take to release priority to other co-routines (listen for rtcm corrections)

Base Station Config

Here is a breakdown of the config variables for the base station

baudrate: The baud rate the base station gps module is configured to communicate at over serial

filename: The path to the device file that the base staion gps module is mounted to

buffsize: The size in bytes that each lcm message should be. Too small of a buffsize may result in the rover module not accepting the rtcm corrections and too large of a buffsize may cause networking issues

Sources

https://en.wikipedia.org/wiki/Real-time_kinematic