Via Hackaday:
Where most GPS receivers only look at the data coming from the GPS satellites orbiting overhead, the Piksi uses another technique, real-time kinematics (RTK), to determine the receiver’s location with exacting precision. The basic idea behind RTK is to look at the carrier frequency of the GPS signals at 1575.42 MHz. This frequency has a wavelength of 19 cm, compared to the alternating 1s and 0s of the that are transmitted at around 1 MHz, or about 300 meters between each bit. While centimeter-level precision isn’t possible with only one receiver, two of these Piksi boards – one base station and one on a vehicle, connected via radio link – can make for a very exacting high-accuracy GPS receiver.
Comments
Hello all; I have acces to a Javad Delta and a UBLOX6-T receiver. In addition I hav access to very expensive simulator. I setup a test profile of high G to see if I could break UBLOX6-t position solution. I setup the UBLOX using UCenter for max dynamic, Aircraft Mode 4g. I used a simple profile and was surprixed that it continued to provide solution well beyond 4g. I am just starting to do this work so Ublox is new to me as is Simulator. But I am fairly confident of results to date. More time will be needed to gain more confidence. The Javad did a little better BTW. Also I used 1sec update rate. At the start of this thread comments about copter use indicated that UBLOX did not work out? I have a thought at this time the mechanical vibrations are modulating the receivers reference clock? Has anyone tried to mechanically isolate the receiver? Or perhaps just the receivers reference clock? I beleive UBLOX ref clock is about 16.xxxMHz? Usally u can find the ref clock by touching it while tracking, the thermal disturbance will typically break lock. The ref clock in all low cost receivers are weak in terms of freq error and drift rate(rate-rate). I do wonder why more attention is not paid to this issue by those wanting high performance as the inherent by design/quality dynamics on the ref clock ( esp non zero rate-rate,ie accel term) can effect performce of solution.
Is all the options really needed?
For example with TR-G3, which is single freq receiver (no need to go higher, for other frequencies, you need special permission anyway) with 20Hz update rate (that should be enough) and with RTCM receive and Advanced MP reduction you end up on something like 4800 USD per receiver. Yes, it is not cheap, but certainly less than 18000
Yep, if you add all the options we need to get RTK working on a copter or perhaps on a rover (100 Hz RTK rate and advanced multipath filtering), you end up at about 18 000 $ for a single module, and you'll need a second one for the ground station.
Remembers me of these
http://www.javad.com/jgnss/products/oem/
they are professional grade GPS receivers, with RTK features - most interesting about them is that they have programmable correlators, so they can basically support any new technology (Galileo for example) with just a firmware update (more here http://www.javad.com/jgnss/products/options/triumph.html )
Yes, they are not cheap.
In this case the only remaining option for better accuracy seems to be an Omnistar subscription. (needs an expensive two channels GPS as well).
Without ground station, using carrier phase on the rover will only give relative precision enhancement, not a better absolute precision.
It seems to me that carrier phase would ask for a very fast acquisition GPS frontend to avoid cycles slips.
And for a rover a few centimeters above the ground, multipathing will be even more challenging with a carrier phase solution. I doubt it can work.
There are other problems poping up implementing RTK on a UAV :
On a copter we have the banking angles problem, that can induce fast phase jumps. Another problem is signal interferences (FPV video transmitter, RC, telemetry...). For RTK to work, the signal must be perfectly clean.
Yet another problem : RTK or other carrier phase solutions convergence can ask for about 30 - 40 minutes... Not very convenient. And do not forget the time needed to get the base station position, something like one hour to get a good static solution convergence.
Without serious antenna mounting and interferences isolation, it seems that an RTK solution on a UAV will perform worse compared to the ublox stock solution.
According to this report, the RMS precision of a RTK solution on a UAV could not be better than 1 meter.
http://www.asl.ethz.ch/people/slynen/personal/student_projects/2012...
Before spending large amount of time on a low cost RTK solution, i think that it would be interesting to try a high end commercial solution on a rover and on a copter, and see if that really works.
@Oliver,
Some vehicle competitions, like the Sparkfun AVC, do not allow a local base station so DGPS is not an option.
Regards,
TCIII ArduRover2 Developer
Hi John Morris !
thx for your fast reply.
i will go decode the 0x6D.
I set TSIP ID=0x35 packet byte 3, bit0= 1, bit1= 1, bit3 = 1 enable raw.
I sent TSIP= (byte0=0x13,byte1=0x02,byte2=0x00,byte3=0x0B),
the receiver should return 0x55 packet but it did not.
1- could the 0x35 be turned off ( firmware ) ?
1- besides iQlassen have you tryed Copernicus ?
regards,
julio
PS: I wanna develop under GPL for GNU/Linux.
I just start some code to see the receiver capabilities. ( Trimble is one market leader )
Here is an interesting table comparing DGPS vs RTK solutions for farming GPS applications.
http://www.agri2.com/index.php?page=accuracy-en
I still think that if we can get DGPS working correctly with a local base station, it will be enough for our use with about 10 cm precision and without the hassle of RTK phase jumps.
@Steve, that's fantastic news! Thanks!
For those that have not backed (or who aren't following) the Piksi Kickstarter Project yet... they just released an update: "I know a lot of our backers are flying APM based systems. I wanted to let you all know we are teaming up with 3D Robotics to integrate Piksi with APM and make sure that ArduPilot is one of the earliest supported systems."
Sounds exciting to me!!