Evaluating the 3DR uBlox LEA-6H GPS
I my never ending quest for a better GPS receiver for my autonomous car, I finally got my hands on a new design from 3D Robotics that's based on the LEA-6H chipset from uBlox. This receiver created a bit of a stir at last year's AVC 2012 when Chris Anderson, the CEO of 3D Robotics showed it off in his autonomous ground vehicle entry. As delivered, the 3DR uBlox LEA-6 GPS is setup to deliver position and status data in a binary format, not in the NMEA sentence structure I was used to. But, after reading the spec, I decided that this might be better, as the latitude and longitude values are delivered in fixed point binary format, which is actually what my code is designed to use. Getting binary values direct from the receiver avoids the loss of accuracy problems I had run into with the receiver I used last year, so that looked very promising.
My first attempt at getting the uint working was very frustrating, as it just didn't work. However, I eventually figured out that the module I'd received was missing a component and that was the source of my problems. The 3D Robotics people replaced my unit and I was up and receiving data within a few minutes of plugging in the new module. However, when I looked deeper, I discovered that the structure of the binary commands needed to enable and disable certain features in the LEA-6H was more than a little complex. Much of this complexity is due to the wealth of configuration options that are possible with the LEA-6H, but the lack of concrete examples for doing basic things, such as setting which data messages are sent from the receiver, made working with the module very frustrating at times.
Click to see larger image
The first test I ran was to write code to log and capture an hours worth of latitude/longitude data in the parking lot at Lake Miramar, which is a few miles from my apartment and was my attempt at finding a location that mimicked the new AVC venue at Boulder Reservoir. I also captured a value called "hAcc" which is provided in the basic navigation data message, NAV-POSLLH. This value is described in the documentation as a "Horizontal Accuracy Estimate" and its units are expressed in millimeters. I was curious about how well this value would do as a metric for the accuracy of a fix, so I decided to compare it to a chart of the distance the gps fix strayed relative to the average position, as computed for the full hour of recorded data. The results look like this:
Note: Standard Deviation for these values is 0.240
The vertical scale shows the distance a given position fix strays from the average position fix, which is computed as the average of all latitude values and the average of all longitude values. As you can see, the worst case position fix is only about 1.3 meters away from the average position fix and, as the average line for this chart show, the average distance is about .5 meters, or about +/-20 inches. The average value computed for hAcc from this same data run turned out to be 476mm, or +/-19 inches, so it seems that hAcc is a pretty good metric for the relative accuracy of a given fix. For comparison, here's a chart that shows the hAcc values over the same test interval:
As you can see, the value for hAcc starts off rather high, but it's important to note that this was a cold start of the LEA-6H module, so it probably took some time to update all its satellite positions and settle in on a stable reading. However, it's also curious to note that, even though the hAcc values are rather high at the start of the test, the value on the first chart shows very good readings for this same interval. Unfortunately, even an hours worth of data is still not enough to evaluate the effect of changes in the GPS satellite constellation over time. So, if time permits, I'd like to do a longer run at some point in the future. Nevertheless, I'm very impressed with the precision of this unit and plan to upgrade my car to use it.
Example Code
I've added an Arduino sketch to the attachments section below that demonstrates how to display various kinds of data from the uBlox LEA-6H. This code is designed to run on an Arduino Leonardo, as its separate USM interface frees up the serial ports to talk to the LEA-6H. However, you should be able to modify this code to use SoftwareSerial in order to run on a different model Arduino board. If you try this code, it will print out a continuous stream of information formatted like this:
Time: 113886500
NAV-SOL: week = 1733, gpsFix = 3, pDOP = 2.12, pAcc = 589 cm, numSV = 8
NAV-STATUS: gpsFix = 3, dgpsFix
NAV-POSLLH: lon = -117.1141278, lat = 32.9199514, vAcc = 4863 mm, hAcc = 3316 mm
NAV-DOP: gDOP = 2.50, tDOP = 1.31, vDOP = 1.78, hDOP = 1.14
NAV-VELNED: gSpeed = 23 cm/sec, sAcc = 90 cm/sec, heading = 153.74 deg, cAcc = 38.00 deg
NAV-SBAS: geo = Anik F1R, mode = enabled integrity, sys = WAAS
When you connect the LEA-6H module, be sure to connect RX pin from the Leonardo to the RX pin of the receiver and the TX pin to the PX pin, as the pad labelled RX on the 3DR module is the output signal and the TX pad is the input signal.