Recent developments in using single-frequency dual-satellite navigation system for RTK application (L1 GPS + L1 GLONASS, or L1 GPS + B1 Beidou), with more satellites overhead at any given time resulting in much higher availability getting ambiguity fixed solution, it has brought lower-cost single-frequency centimeter-level accuracy RTK receiver closer to reality. Using GNSS Radar, below figures show what satellite availability might be like over a 12 hour satellite orbit period at different locations.
In East Asia, Australia, and India, there are more GPS + Beidou satellites over the horizon than GPS + GLONASS satellites. In Europe and South Africa, slightly more GPS + GLONASS satellites than GPS + Beidou satellites. In North America and South America, number of visible Beidou satellites is low.
With goal of developing a small low-power single-frequency RTK receiver module, for ease of debugging, initial development of RTK software is done on a PC, with below recent results:
Although above image looks wobble a bit, the result on the athletic track should be good, considering it’s not easy to hold the antenna pole straight and perpendicular to the ground without shifting the antenna slightly.
For comparison, below is from jogging around campus, logged using Nike+ using Galaxy Note 3; four passes over a same route, with fifth path making the smaller round.
With more available satellites using two satellite constellations, time to resolve integer ambiguity achieving fixed RTK solution is much shorter than using single GPS constellation alone (90 sec with 7Km baseline in above example), and it has high availability at any time of day. Above test results show exciting promising potential for emerging applications requiring high position accuracy using lower cost single frequency RTK receiver.
A complete SMD receiver module prototype about the size of 25mm x 25mm will be developed, beginning schematic design next week. A separate interface adapter board will have accommodation for wider power input range, data logging, and other interface if needed. Now at beginning development stage of the target hardware, if there are developers interested in adding software support making this RTK solution workable with Pixhawk or Ardupilot, would be happy to try accommodating the needed hardware interface on the board design. Cheers!
Comments
Here is a recent successful case of using Piksi on a quadcopter getting fixed solution. It uses external antenna on a ground plane to boost signal level, and some RF absorbing material to decrease noise from the flight controller. With existing quadcopters, such ad hoc method may be needed to make it work. New quadcopter hardware design could incorporate additional top and bottom solid ground plane layers on PCB to reduce noise radiation, and optional RF shielding to further minimize noise to make it easier to work with RTK receivers.
RTK receivers mainly works under open sky signal environment, requiring strong signal (> 38dB/Hz) to maintain precise carrier loop phase lock, good spread out satellite geometry (low DOP) with sufficient number of satellites (> 6, some say >8). With GPS-only NS-RAW + antenna + RTKLIB used in open field on a table, if you walk near blocking signal, it easily falls outside the needed criteria and RTKLIB goes from fixed to float solution.
Thank you Tridge for the pointers, it's very helpful. With this information, after finishing the smaller-size RTK board in a month or two, we could try to add the software support and test on the Iris we have.
Sounds great.
I have supported your indiegogo campaign a few years ago and have a pair of the NavSpark RAW receivers and got them to work. However I suspect it would be very difficult to obtain a noise-free enough environment on a drone for them to be used, I even have problems when they sit on a table and I'm walking too close. I hope we find ways to improve this while keeping relatively small antennas.
By the way do you plan on open-sourcing your future RTK firmware or your PC development code?
Hi Oliver,
For ArduPilot compatibility the easiest route is either a simple UART or UAVCAN. After that what is needed is a AP_GPS driver. If you have a look at the AP_GPS directory you will see we already have quite a few GPS drivers, including one RTK capable receiver (the Piksi, which uses the SBP protocol).
When we add a new GPS driver we also prefer to add a SITL simulation of the receiver so that we can test that it works when structural changes are made to the GPS library. The simulated GPS drivers are in sitl_gps.cpp.
For RTK protocol input from the ground station we use GPS_INJECT_DATA MAVLink message. That allows for arbitrary data to be sent by a GCS to the aircraft to be injected into a GPS. Typically this would be RTK observations, but it can be any data you need to send to the GPS.
Good luck with the project!
Cheers, Tridge
The integer ambiguity in my brain is still unresolved but this looks like exciting stuff! Nice work!