GPS

Moxom's Master has a NavCom SF-2050M GPS ( datasheet,  user guide,  other docs), which theoretically provides 10 cm accuracy when used with the NavCom corrections service. Precise Path, who donated it, report that we can expect more like several feet of accuracy in the real world, which should be sufficient for the navigation challenge.

Previously we used the Garmin "16x HVS 010-00258-63"  (datasheet), which costs $110. It is intended for nautical use. It supports Coast Guard DGPS corrections and sports an RS-232 interface.

Interfacing with ROS

There is a third-party ROS package called  gpsd_client which relays data from the GPS into ROS. Details on installation and testing are found in  this tutorial. The package should be installed under ~/ros-stacks instead of the directory that the tutorial suggests, so that the user has full read/write permissions. Compile the package using:

$ rosmake --rosdep-install

GPSd

We use a Linux utility called  GPSd to interface with the GPS; this means that we don't need to mess with tedium like parsing the NMEA messages used to communicate. Under Ubuntu the GPSd daemon isn't automatically started when you install it because it must first be configured with the serial and/or USB interfaces to communicate on. To do this configuration run the following command:

sudo dpkg-reconfigure gpsd

Specify the option -n so that GPSd connects to the GPS and attempts to get a fix before our software does; this should decrease start-up time.

Troubleshooting

View streaming data

Run this command:

python /usr/lib/pymodules/python2.6/gps/gps.py

Checking for a GPS

First, check whether GPSd has discovered anything on the interface on which it's listening with the gpsctl utility:

moore@moore:~$ gpsctl
gpsctl: gpsctl: /dev/ttyS2 identified as Garmin Serial binary at 9600

This example shows the Garmin 16x GPS (the black dome). The Navcom GPS looks like this:

rhrt@moxoms-master:~$ gpsctl
gpsctl: /dev/ttyS2 identified as  at 57600

If no GPS is connected it will look like this:

moore@moore:~$ gpsctl
gpsctl: gpsctl: /dev/ttyS2 identified as (null) at 9600

However, if the GPS has become disconnected since it was successfully identified by GPSd the identification may stick around. You can clear GPSd's memory by restarting it with sudo service gpsd restart.

Debugging

To debug things, run gpsd -n -N -D 1 /dev/ttyS2 (you'll need to stop the background daemon first if it's running with sudo service gpsd stop. There should be a significant amount of chatter printed as GPSd determines what type of GPS it is connected to, such as:

moore@moore:~$ gpsd -n -N -D 1 /dev/ttyS2
gpsd: garmin_gps not active.
gpsd: => Probing device subtype 0
gpsd: GPGSV field 3 value of 10 != actual count 2
gpsd: => Probing device subtype 1
gpsd: => Probing device subtype 2
gpsd: unknown sentence: "$PGRMT,GPS 16x-HVS software ver. 2.90,,,,,,,,*7E\x0d\x0a"

There will be more if it can actually get a fix. If you increase the debug level (-D 1) it will be more obvious whether there is actually anything going on -- at -D 1 a GPS that isn't present looks much like a GPS that is. For reference, the messages are as follows when a GPS is not connected (note that the debug level has been set to 4):

moore@moore:~$ gpsd /dev/ttyS2 -n -N -D 4
gpsd: launching (Version 2.38)
gpsd: listening on port gpsd
gpsd: Unable to start ntpshm.  gpsd must run as root.
gpsd: successfully connected to the DBUS system bus
gpsd: running with effective group ID 1000
gpsd: running with effective user ID 1000
gpsd: opening GPS data source at '/dev/ttyS2'
gpsd: speed 9600, 8N1
gpsd: => GPS: $PASHQ,RID*28\x0d

gpsd: => GPS: 0299661c0800040200001203
gpsd: Navcom: sent command 0x1c (Test Support Block)
gpsd: Navcom: command 0x1c mode = 02, length = 0
gpsd: => GPS: 029966200e000001ae02000071000000f203
gpsd: Navcom: sent command 0x20 (Data Request) - data block id = ae at rate 00
gpsd: => GPS: 029966200e00000186020a0071000000d003
gpsd: Navcom: sent command 0x20 (Data Request) - data block id = 86 at rate 0a
gpsd: garmin_gps not active.
gpsd: no probe matched...
gpsd: gpsd_activate(1): opened GPS (5)

To see a plot of the fixes the GPS is getting, use this command (you'll need the gnuplot-x11 installed):

gpsprof | gnuplot -persist

See the gpsprof man page for more information.

Background Information

In order to accurately determine the robot's position, as well as navigate to specific waypoints in the navigation challenge, we need a GPS; preferable one that will provide accuracy <1m. Generally, two ways of obtaining this kind of accuracy are DGPS and RTK (a decent  summary).

RTK equipment is likely to be very expensive, especially because it requires a base station as well as the unit on the robot. This is very likely to exceed our allocated budget of $500. However, it would provide us with about 1cm accuracy.

DGPS is the less expensive option, but it is also less precise. There are many correction signals being broadcast for DGPS, the most widespread of which is  WAAS. Ideally, WAAS could provide up to 0.9m resolution. WAAS has coverage across the US. Another correction signal is  NDGPS provided by the US Coast Guard. Unlike WAAS, this is not nationwide, but it has excellent  coverage at the location of the competition.

We should look into GPS receivers which could make use of these correction signals, and also check to see if any receivers support corrections from both systems.

Here's a relatively cheap GPS which would provide <3m resolution:  Garmin GPS 15H. While not ideal, it's cheap and also has a corrections input, so we could play with using two correction signals to try to improve accuracy (admittedly, I don't know how well that would work). Also, <3m accuracy may be sufficient. We have at least one other sensor capable of positioning on the robot now (the accelerometer), and will likely be adding wheel encoders as well. By combining these with a Kalman filter, we could potentially get pretty decent accuracy.