-
Notifications
You must be signed in to change notification settings - Fork 276
Introduction to RTK
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.
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.
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.
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.
Note: If you are having trouble executing the code assume super user privileges by appending sudo
to your ./jarvis exec
commands.
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.
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 is located in config/gps
and holds configuration information for both the base station and rover gps code.
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)
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
Something not right? Contact the Software Branch lead.