RTK GPS for Outdoor Augmented Reality

What is an RTK GPS system?

Basically, GPS is inaccurate. I'm sure I've mentioned this before but if I haven't, it it. Very, very inaccurate. It may not seem that way because of the way we use GPS to help us locate ourselves and get directions, but often this is because averaging a position over a greater period of time leads to greater accuracy, and a constant heading is more accurate than standing still. Portable devices may have an accuracy of 5m-10m radius under the best circumstances which means while you are standing still the device things you are wandering around in various directions (a phenomenon known as "drift"). But RTK GPS systems use a signal called "correction data" from a base station at a known, surveyed point to locate roving units at an accuracy of 1 cm over several miles. This is the sort of accuracy required to do outdoor augmented reality. Instead of talking general theory I'm going to get down to the nitty gritty technical nonsense one might have to endure to set up a system like this (if you are interested, I recommend http://www.tinmith.net/ or http://www.tinmith.net/wayne/thesis/piekarski-ch0-start.pdf for a little light reading on the most advanced self contained units being used in university research). My hope is not even that someone might try and replicate the system, but more that the general technical tidbits may be otherwise useful.

During the summer of 2012, on top of my usual job running the augmented reality lab at York University, I've been working to help set up the Augmented Reality Research Lab in the Centre for Digital Humanities at Brock University in St. Catharines. In addition to the Intersense 900 hardware we have at York, John Bonnett, CRC at York also has a couple of RTK GPS devices that he's been anxiously waiting to get into the field. Fortunately, most of the tedious stuff was taken care of for me. Thanks to the UART Augmented Reality Plugins for Unity from the AEL in Georgia Tech I was able to unify the tracking technologies in the lab into one software, just as we'd done at York. The only thing that hadn't been done yet in our lab was to work with the GPS devices. One other handy addition to VRPN library from Alex Hill at Georgia Tech was the first step in getting one of these RTK GPS devices reporting positional information to talk to Unity.

 We are using the following configuration:

• Head Tracking: Intersense InertiaCube 3 connected by serial adapter to Keyspan Adapter to USB and powered over USB. 
• Camera: Point Grey Firefly2 over Firewire (to PCI card with external power source). 
• HMD: emagin z800 (modified with Dual Rachet Headband). 
• GPS: Magellan Zmax Thales RTK base/rovers with a Magellan U-link radio and external GNSS-750 GPS Receiving Antenna. 

VRPN
The first challenge was simply getting these GPS systems talking to the computer. After a little digging through the technical manuals, I realized that the line was dead because by default there is no NMEA data being reported. This is where the $PASHS,NME commands come in. The Fischer Plug on Port A of the unit connects, via serial cable (an extra component at $200), to a keyspan adapter making it USB compatible. Firing Up Wincomm (9600, 8, N, 1) I could connect to the device. The manual is out there online  and it appeared that to get this talking like a normal GPS device I needed to input $PASHS,NME,RMC,A,ON,0.2 $PASHS,NME,GGA,A,ON,0.2 $PASHS,NME,GLLA,A,ON,0.2 With positional information streaming from the rover, I at least had a sense this was possible to do. The most daunting hurdle was that for some reason VRPN wasn't talking with my GPS device. It was talking fine to my bluetooth GPS device (sort of) but it took a clue from Russell Taylor (University of North Carolina) that the RTS bit wasn't being set. With that added to the VRPN_Tracker_GPS code, the device finally started filling the cue (cbInQue). A couple more tweaks to the GPS code and VRPN was ready to use, with the GPS, in Unity.

Unity
I found the examples in UART for using GPS systems in Unity quite good, but I was a bit concerned (needlessly?) about the conversion happening to transform latitude and longitude to meters (units) for use in Unity's coordinate system. I couldn't pass up an opportunity to use Vincenty's formula wrapped up with a bow in C#. More details on that to follow.

DragonFly 2 Cameras
The trickiest part was wiring a solution for these cameras. Not being a big electronics person (remember my former post on soldering? I've gotten a *bit* better since then) I was caught in this seemingly endless debate online about whether or not an Amperage rating matters. However, instead of having to worry about heat issues on top of that (dropping the voltage, etc...) I thought these little 12VDC ryobi packs would be perfect: http://cheesycam.com/cordless-tool-batteries-solid-dc-power-packs/ And indeed they have been. After finally tracking down the right size plug for the Firewire card (hint: try an external USB hub power supply) it was just a matter of adding a switch and a 12Ohm resistor to the mix to ensure only 1Amp was running throughout the circuit. 

How does everything fit together? Where's the source code? More soon...