Real Time Kinematic (RTK)

Real Time Kinematic (RTK) is a technique used to improve the accuracy of a standalone GNSS receiver. Traditional GNSS receivers like the one which we use in mobile phones or a GPS puck could only determine the position with 2-4 meters accuracy, but the GNSS RTK receivers provides centimeter level accuracy.

GNSS RTK receivers measures distance by comparing a code generated by a satellite with the same code generated internally in the receiver. The time difference between the two codes multiplied by the speed of light gives the distance.

There are 2 receivers used in the RTK:

1. Base Station
2. Rover

Base Station

It is a GNSS receiver installed at a location whose precise position is computed by other independent precision methods of survey. It computes its location also using the GNSS and computes error in this measurement by comparing it to its precise location. These errors are transmitted in real time to the rover.

Rover

It uses the correction data to improve its own computed position from the GNSS and thus able to achieve centimeter precision. RTK is mainly used for applications that requires higher accuracy such as cadastral surveying, construction activities and drones navigation. It also saves time, energy and cost, allowing more work to get done with accurate results.

Sources of Error

• Orbit errors
• Satellite clocks
• Ionospheric delays
• Tropospheric delays
• Receiver Noise
• Multipath

Stationary Data Plots

Scatter plot	Line plot

Walking Data Plots

Scatter plot	Line plot

Compensating Errors

Every error has it’s own way of compensating it, such as:

1. For compensating Satellite clock error, one need to download precise satellite clock information from a spaced based augmentation system (SBAS) or precise point positioning(PPP) service provider.
2. Ionospheric and tropospheric delays can be compensated by differential GNSS and RTK systems.
3. The simplest way to reduce multipath errors is to place the GNSS antenna in a location that is away from the reflective surface.

Follow the steps to perform experiment of parsing the $GPGGA message from GNSS puck

1. Set up the GPS puck

If you are using a virtual machine, like virtual box, you may have to:

1. Connect the USB.
2. Go to the Settings of the VM
3. Select the USB settings from the left pane
4. Add the USB device in the list from by clicking on the icon
5. Boot the VM with the USB device plugged in
6. Make sure the device is selected/captured in USB settings (click on it) before you can see it in /dev/ttyUSB* When you will connect your GPS device, you can see the device name with this terminal command.

$ ls –lt /dev/tty* | head

You will see a list of devices from which you have to figure out your device file identifier. Let us say it is /dev/ttyUSB2. Run this command without the GPS plugged in, the missing COM port is your GPS device. Then you need to set the read write permissions for reading the device properly.

$ sudo chmod 666 /dev/ttyUSB2

Get minicom with:

$ sudo apt install minicom

Configure your device’s settings in minicom:

$ sudo chmod 666 /etc/minicom
$ minicom -s

Go to serial port setup, Ctrl-a p, change the Bps/Par/Bits to “4800” and Hardware Flow Control to “No”. You will have to scroll through a series of Bps values by selecting prev or next. For example, if minicom is set to 9600 Bps then select prev to get 4800 Run minicom with :

$ minicom

To save data to a text file, you need to use –C flag on minicom. In minicom, Ctrl-A brings up your options, including to exit. Save as gps-data.txt. When you want to stop writing to the file, press “Ctrl-a” and then “x” To check the contents of the file:

$ more gps_data.txt

2. Write a Device Driver for GNSS puck to parse $GNGGA

The GNSS puck provides several differently formatted messages. We will focus our attention on the messages that are formatted according to the $GPGGA format.

1. Ensure you can read the data from the puck (If you do not have the puck, you can use minicom as a virtual puck & the same driver should work with the real puck)
2. Parse the $GNGGA string for the latitude, longitude, and altitude. We have provided an example device driver for a depth sensor in the appendix section so that you can use that as a template
3. Convert the latitude & longitude to UTM.
4. Define a custom ROS message (called gps_msg.msg) with a Header, Latitude, Longitude, Altitude, UTM_easting, UTM_northing, Zone, Letter as fields.

• Please match the naming & capitalization
• Ensure correct data types.
• The Header is supposed to be a ROS Header data type. This is very important especially when you start working with tfs and do sensor fusion in ROS
• The Latitude & Longitude are supposed to be signed floats.
• The ROS Header should contain the GPGGA time stamp & not your system time (as it may be out of sync which could cause problems in a real-world system).
• The frame_ID should be a constant “GPS1_Frame” since our publisher is giving us data from the solo GPS sensor we gave you.

5. Your ROS node should then publish this custom ROS message over a topic called /gps
6. You now have a working driver, let’s make it more modular. Name this GPS driver as gps_driver_try.py and add a feature to run this file with some argument. This argument will contain the path to the serial port of the GPS puck (example /dev/ttyUSB2 . Ofcourse the puck will not always be at the same port so it allows us to connect it anywhere without the script failing)
7. Even though this driver is now sufficiently modular, on a real robot we can have many sensors & launching their drivers individually can be too much work. This is where we shall use the power of ROS.

• Create a launch file called “driver.launch”
• This launch file should be able to take in an argument called “port” which we will specify for the puck’s port.
• Have this launch file run your gps_driver.py with the argument that was passed when it was launched.
• If you have done everything correctly, run the following command & you should get the same results you were getting at 2.5

$ roslaunch driver.launch port:=”/dev/ttyUSB0” #Or basically any ttyUSB*

3. Go outside and collect data

1. Stationary data outdoors: In a new rosbag recording, go outside and collect 10 minutes ofdata at one spot. Name this rosbag “stationary_data.bag”
2. Walk in a straight line outdoors: In a new rosbag recording, walk in a straight line for a few hundred meters. Name this rosbag “walking_data.bag”

4. Data analysis by plotting

1. Read the rosbag data into MATLAB (requires ROS toolbox) or python (make sure you install bagpy with pip3 install bagpy, etc.):

References:

• https://jmscslgroup.github.io/bagpy/installation.html
• https://www.mathworks.com/help/ros/ref/rosbag.html
• https://www.mathworks.com/help/ros/ref/readmessages.html