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
Now I see what happened! It's not that this thread is being ignored by some, it's that they dove into it like I did and now there is a lot of discussion on the Swiftnav discussion group here: https://groups.google.com/forum/#!forum/swiftnav-discuss
(I should have known! I'm still rather new, so just starting to recognize some names.)
Some of the exact questions raised here are now being discussed there.
Fergus Noble, the CTO of Swift Navigation, is very active and personable, which is great. In fact, there must be discussion going on behind the scenes with 3DR because he said, "Totally agree about tunnelling through MAVlink packets, looks like 3DR might be interested in making this happen too so stay tuned on that one." (Here: https://groups.google.com/forum/#!msg/swiftnav-discuss/4SKs556XT2w/rfNMbzJUitEJ)
Not that I want to discourage this excellent thread, this is just FYI. :-)
Julio,
I've interfaced to the Lassen IQ receiver, but I never figured out how to get carrier phase. There is a "raw data" message 0x5A, but it has only CA-phase and Doppler. Looking back at my code, I configured the IQ with a "35 11 00 00 01" message, and I got a 6d message in response.
Have you figured out how to get carrier phase from the IQ?
- John Morris
Dear all,
I have a Trimble iQlassen and i am trying to get raw carrier phase from it.
I plan post-processing the UAV colected GPS data.
I wrote some C code and sent the 0x35 to iQlassen TSIP port at 9600,ODD... taking care about Big x Little endian.
I am not getting the 0x55 return from 0x35 setting, even sending 0x3a request command.
Packets 0x4A position, 0x56,0x6D,0x82... are ok.
Does someone has or have used this receiver ?
thx in advanced,
Julio
Hello, new here to your UG and excited to find such expertise in dGPS. I have similar requirements as stated by Eric T on August 6, 2013 "Precision=no drift, so when I set my tractor to drive on 120 foot centers while spraying expensive chemicals, it will always have the next pass be 120 feet over, with no overlap or misses. With normal GPS, depending on the day the signal can drift 6inches to 2 feet".
I built a custom miniaturized test rover last year (26"W x 36"L, R/C & wireless receivers) for my experimentation/research project. Also developed server-side mapping software attached to wireless router now running on laptop. The maps are any user defined acreage/area, divided into zones, further divided into (26"W x 36"L) blocks. My objective is for server to continually process the rover's sensor data and GPS telemetry via the wireless connection, re-calculate and transmit back to the rover it's next-new target block position. However, unlike other poster's UAV high speed requirements, my vehicle only operates at speeds up to 5 mph ... "Precision=no drift" is my priority. Other posters have suggested using a base station to calculate GPS error corrections which seems perfect for me to attempt in my server-side processing. Does the base station have to be a permanently mounted "GPS surveyed" device or can my server software be running on a fixed positioned laptop? If I allow enough start-up processing time to calculate it's own GPS location will it be accurate enough to be used as the error differential?
I am considering upgrading the rover to Netduino Plus2 with Adafruit's Ultimate GPS and a separate Ultimate GPS for the server. Not sure if Ultimate GPS accepts external GPS error correction data. This is a learning experience for me. I hope others with much more experience can point me in the right direction. If I can get this working with high accuracy, gladly share software. Any and all suggestions on possible hardware configurations and ideas appreciated. Thank you for sharing your knowledge!
Concerning the use of DGPS and RTK with drones …
DGPS is submeter only with dual frequency base stations. Single frequency base stations are much less accurate, mainly because they can’t distinguish between atmospheric and multipath errors. Their corrections are generally good to two meters or so.
RTK is very attractive, but it is difficult to establish high accuracy RTK on a moving platform. The big issue is cycle slips. Undetected cycle slips destroy RTK accuracy.
With single frequency receivers, we have to come up with other ideas. For example, we could establish RTK on the ground and hope we never lose it during flight. Or, we could use accelerometers to adjust for the drone’s unstable velocity until RTK is established. Or we could integrate WAAS with DGPS to try to improve the corrections. The problems aren't impossible, but they are a bit of a challenge.
@monroe
Why dont you start a kickstarter ?
Regarding the "4G limit", the Kickstarter page says:
"We previously worked at a company named Joby Energy where we successfully developed an RTK GPS system for high-altitude wind turbines. This system was used to guide UAV’s in highly dynamic environments (greater than 8g accelerations, over 100mph)."
From what I've read in this thread, I think that would be sufficient for everyone here, right?
And from the documentation, "It supports 3-bit, 16.368 MS/s L1 front-end supports GPS, GLONASS, Galileo and SBAS signals." So I think that's part of the trick.
I agree it is a cool project, so I intend to support it. I'm just not yet decided at what level.
(BTW, I'm new here-this is my first post. I want to learn, so I appreciate the helpful attitudes here.)
I should add that if a receiver is allowed to sit and average for a long while the position error ball shrinks as the noise tends to average out. But on short time scales you are up against the jitter limit in single code based measuremnts of around 10feet.
Oliver/Steve/Others;
I am not that experienced with DGPS/RTK GPS app...what I do know is the "guts" of the measurement proceses in the receivers themseleves. Without diff solution a standalone L1 receiver cannot correct for iono/trop errs in range to a SatVeh from rec., and these err's can 100meters or more. With DGPS two rec are viewing the same SV at same time the Iono/Trop erro is about the same , assuming reasonable base line between the two rec., limit is in the miles? Since the iono/trop error is about the same it subtracts away in a diff calculation. To bring carrier phase into measureme opens up the "phase jumps" or cycle slips problem. A good comprmise is a reciver that smooths its code based measurements with carrier phase data...some do a better job at this than others.
For those reading this there are two basic range to SV measurements in a GPS receiver, code and carrier. The code mesurements r based on 1Mhz code rate ( the C/A code rate) the other is based on carrier at 1575.42MHz. The rule of thumb is your jitter or noise in a single measurement of range is about 1/50 of a cycle. For the code based measurements this works out to 1usec/50 or 20nsec, @ 1nsec/ft for speed of light thats a jitter of 20feet. For carrier based (1/1575.420Mhz)/50 or 12pico seconds, or 0.012nsec, or 0.012 feet. So carrier measurents are SUPER precise but cannot be used easily due to cycle slips and ambiguity issues (SV range is expresed as a huge integer number of cycle cts plus a fraction)
There is lower cost timing receiver from trimble that provides all carrier and code based measurements, raw and unprocessed. Very similar to UBLOX 6T. If two r used its concievable to rol your own DPGS/RTK measurement system witha radio and the code to process measurements.
Dan, is it really necessary to use RTK, when DGPS with a local base station can give about 10 cm accuracy and seems precise enough for our use ?
If 10 Hz RTK could be ok for farming, i doubt it will work on a copter with less than 100 Hz acquisition rate because of the small wavelength of the carrier (about 20 cm). 100 Hz GPS modules are not really cheap.
To avoid phase jumps, i think that the max distance between two consecutive acquisitions should be not more than 10cm (1/2 wavelength). At 10 m/s, 0.01 second is needed to get a 10 cm move. This translate to a 100 Hz acquisition rate to keep a 10 cm precision at 10 m/s.
At 30 m/s, a 300 Hz acquisition rate would be needed to keep RTK working.
The advantage of DGPS is that it is using a pseudorange only solution, so the problem of phase jumps and fast acquisition rate L1 / L2 expensive receivers are discarded.
The only concern with DGPS would be correction latency, i can't find practical informations about the correction latency when DGPS is used with a local base station. Do you know what we can expect here with RTKlib, and if the RTKLib DGPS solution is reliable ?
-
1
-
2
-
3
-
4
-
5
of 6 Next