Realtime DGPS with ublox and GPSTk lib processing, relative <1m?

I've read through a few discussions on this forum about poor man's DGPS and getting relative accuracy down to the ~1m range.  It seems no one's having much luck even with identical GPS units.  I'm wondering if anyone has manged this and what are your thoughts on what I'm currently building.

 

I'm laying out a PCB for a ublox LEA-6T (that's the one that outputs raw data and carrier phase) to interface to a MCU and a 433MHz radio.  That's the mobile unit.  My base station is then a single board computer with it's own LEA-6T, radio, and software running GPSTk post-processing software.  The mobile board will then radio the raw data (subframes 1 and 2 and psuedo range and carrier info) to my base station.  Base station code then chooses a set of sattellites that work well for both units and calculates position of both units using the same satallites and same ephemeris data.  (calculated position could then be radioed back to mobile unit)

 

The units are genearlly pretty close to each other (spatially) so the only error here should be that inherent to the ublox measuring psuedorange--no constellation, algorithm, iono/troposphere, ephemeris differences.

 

Has anybody tried this?  Do you think I can get a relative accuracy of ~1m?

 

 

Thanks for any thoughts guys and gals!

 

Views: 33615

Reply to This

Replies to This Discussion

Well, that's the theory. If you can pull off the implementation, you should get accuracy better than 1 meter.

I personally think the best way to sub-meter precision is to do tightly-coupled GPS/INS.
Poor man's GPS only works if you have a fix on the exact same satellites at the exact same time (and sometimes not even then).

That said, I believe that the ublox binary protocol has the information you could use to create your own actual DGPS corrections from a base station. I've been thinking about experimenting with that, but haven't gotten around to it.
Yeah, I'm a little confused about that. I will only calculate base station position and rover position using exactly the same satellites, eg:
Rover is fixed on SVs 1,5,8,12,13
Base station is fixed on SVs 1,5,8,22,13

I would use the psudoranges from 1,5,8, and 13 to calculate a position solution.

The problem I guess is I'm not sure how the ublox calculates its pseudoranges. Doesn't it first have to get a position fix to do some interation to arrive at it's clock drift value? So somewhere in the calculation of each individual psuedorange, information from all satellites in fix are used. And there's no way of ensuring they're the same set for both rover and base. Does that make any sense?
I have a LEA-6T. The RAW data *i think* is RAW and just the collected measurements from each SV. Then, after collection it's "processed" into the NMEA and other messages. I've also found that if you keep the antenna fixed for about 12 hours, PDOP goes down incredibly. However, post processing the RAW data in near-real time, via Kalman filter , might be a bit much for an 8-bit micro-controller. (Please correct me if I'm wrong).

Now, if you go 32-bit and 333+ Mhz, it's completely do-able. :-)
Yeah, wasn't going to attempt post-processing on an MCU, just radio the data to a single board comp, 800MHz style.

Wonder if anyone out there has compared the output of two LEA-6T units: when their antennas are in the same place, do they output the same pseudoranges to within 1m?
Given 2 identical units, separated by 1 meter apart, and then corrected for atmospheric delays should provide 2 different locations. So, the psuedoranges should be different - as this is done with DGPS and RTK to as far down as millimeter levels in some applications.
Really? This is exactly what I want. I just hope I can extract all the right info from the ublox and do the right calculations with GPSTk. I am trying exactly this with 2 identical modules based on SiRFStar III chipsets and the results are terrible--the units appear to be anywhere from 0 to 30m apart!!

What makes the SiRFStar so much crappier than the ublox? I read that SiRFStar smooths it's "raw" data, wonder if that's all it is. And it doesn't output carrier info.
I don't know about the SiRFStar at all, but just because the same chip is used in the module, doesn't mean quality is good. For example, I used some GPS modules with the same chips that GARMIN uses from a Chinese company. The Garmin one was better quality.

Ublox is the only company (that I found) that still makes their own chips (for their latest product line) and their own modules. Having said that, their LEA-6T is the only one I found lately that outputs both raw range and phase measurements.

They say the accuracy is <2m which is about right, but let it sit a while and the Std Deviation in PDOP goes down to <0.05 meters.

Does this matter if you're going to Post process? Not really, except that you really want the carrier phase measurements.

Now, other receivers are getting more sensitive. And if they are really sensitive then it creates too much range noise and you can't get phase data.

Ok, so you have raw range and phase data on the single frequency, L1 C/A code. Now what?

On your 633+ Mhz processor you can either use GPStk or RTKLib. If you're using GPStk, I would consider using DDBase. Otherwise RTKlib is already designed for Real Time.

Since you're going to be transmitting data via RF, and RF propagates at the speed of light, then you're drone is only going to be (a few milliseconds * velocity of drone) away from the last location after you've processed the RAW data. I say milliseconds, because it's going to take a few clock cycles on either side to transmit that data.

:)
Hi Tom,

When you say "tightly-coupled GPS/INS", I assume you mean there is a single CPU that is running an single, integrated algorithm that freely uses radio, gyro, and accelerometer information? If so, I agree that you could get sub-meter resolution, possibly even sub-meter accuracy.

We recently implemented a loosely-coupled GPS/INS algorithm in MatrixPilot. It achieves centimeter resolution and high bandwidth, but the accuracy is still only what the underlying GPS provides. Here is how it works:

1. Gyros, accelerometers, GPS, and optional magnetometer are used to compute the 9 elements of the direction cosine matrix (DCM) to determine attitude.

2. Accelerometer information is transformed from body frame to earth frame with the DCM.

3. Earth frame acceleration is integrated twice to provide a high resolution, high bandwidth, velocity and position estimate.

4. The acceleration based velocity and position estimate is filtered with a replica of the GPS dynamic model.

5. The difference between the GPS and replica velocity and position is used to provide drift compensation for the acceleration integrators.

The implementation has been imbedded in MatrixPilot for several months now, there is plenty of flying experience. What we have achieved is the following for position and velocity estimates:

1. Centimeter resolution.
2. Full PWM bandwidth.
3. Compensation for GPS dynamics.
4. Capability of continued navigation during brief GPS outages, such as during turns.

However, the accuracy is still the underlying GPS accuracy. Basically, unless there is "tight-coupling", there is no way around this. In order to improve things any further, in my opinion, the INS information will have to be fed back into the GPS calculations.

By the way, one of the discoveries that we made along the way, when Peter Hollands landed his plane in a tree, is that the dynamics of the uBlox and the EM406 are comparable. During the flight in question, the uBlox reported the plane was flying for 2 seconds after it stopped in the tree. The recorded response suggests that the dynamics of the uBlox approximates a 2 second moving average.

Best regards,
Bill
Hi Bill,

That sounds like a really cool algorithm! What kind of processor / uC are you using to run that? Are you using an EKF for data fusion? May I have a peek at you're awesome work. :-)
Hi Mike,

The algorithm, attached, is running on a dsPIC30F4011. Actually, it is rather simple. I am not using an EKF for data fusion, but that would probably be a good idea, and would improve performance a bit. What I am using seems to work well enough. It is a simple negative feedback scheme. Each time new GPS information comes in, the GPS replica data is subtracted from it to form an error signal. The velocity error provides negative feedback for the integrator that accumulates acceleration into velocity. The position error provides negative feedback for the integrator that accumulates velocity into position.

Best regards,
Bill
Attachments:
Hi BIll,

Thanks, It looks nice I'll have to give it a try one of these days. What measurement rate were you running the u-blox to get the 2 second drift? not sure if 1Hz or 5Hz would make a difference. Also, what are you using for your Clock? Unless you're using a crystal or the PPS from the GPS receiver, could it be likely that the 2 second drift could be from the micro-controller?

Thanks,

Mike

Reply to Discussion

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2017   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service