I’ve just submitted my thesis for examination. I’m a Master of Research candidate at Macquarie University, Australia. The MRes program is not quite the same level as an MPhil, however it is classified as one AQF level above Honors. Anyway, here’s the details. Feel free to skip to the actual positioning details further down. 
I study Earth and Planetary Science, mostly Geophysics, but I have a Major in Geology as well. I have a hobby interest in UAV’s (Drones/UAS/RPA, etc) so when my favourite uni professor said he had a project in that area I jumped on it.
More or less the aim was to attach some miniaturised geophysical equipment to a small UAV (<2kg), and see if we could tackle UAV geophysics in the opposite manner to everyone else, who have big sensors and have to build a big drone.
We started out as a 3 man team, with myself handling the position refinement, which led to me finding the Reach module. I must say, it’s been the best part of my year working with such a fantastic and polished product. Unfortunately the 2 other MRes candidates changed project, and I took on the sensor design and implementation in addition to the positioning.
Actual Positioning Information
The actual positioning project itself was simple. DGPS is great, but paths recorded by it when satellites change, base station drops out, you lose Fix status, etc can have deviations, side tracks etc. I was also interested in refining the single mode positions. For this, my supervisor suggested the Kalman filter. You’ll recognise the name, it’s used pretty much everywhere, including combining satellite range information to output a best fit position solution. The nitty gritty is in the PDF if you are interested.
From the Reach side of things, I used it in ground surveys, where it performed brilliantly, and the aerial surveys. For the UAV system, I was stuck with a DJI 3. I had to use an 8cm diameter mini CD as the groundplane, stuck to the top of the DJI, which may have worsened reach performance. The DJI was operable but unhappy with its on-board GPS reception limited. Nonetheless I got some good flight tracks to filter. For the field survey, I had a second reach module base station with SiK radio link.
Here’s the field lines I simply walked while surveying the line markings for the survey area info. The painted lines weren’t very good when the imagery was taken! I used Reach’s survey mode to waypoint some targets, which are shown.
The Reach output location data over serial to an Arduino Mega 2560 I was recording magnetic fields with. I did build a custom UAV with Reach on board, but I didn’t have time to tune the custom system for the sensor array weight.
Here’s an image of the UAV recorded paths. I did 2 flights, North and South. I was limited to GPS, QZSS and SBAS for 14hz update. I also had the smaller ground plane as noted.
I’ve chosen just two path filter results to show here, one for the field recorded DGPS, the other for the a single mode track I processed from the logs.
Here’s the first - Performance of the Kalman filter on a large deviation in the Northern Flight.
And the second is the single mode recording of another survey (that I had a CORS monument 6kms away). The red line shows the single mode performance, which is a bit messy. The blue line is the Kalman filtered track, using only the recorded track as input. There is some overshot at corners from my filter tuning and inputs, but it’s pretty dang great. The Black line underneath is the post-processed DGPS track.
Magnetics results are shown in the attached PDF if you are interested. I think I was severely hardware limited on this front, but yeah… Future works.
Finally, some Reach specific things to talk about.
-
I’m keen for the Reach IMU to be enabled. I don’t know how it will be implemented, but even logging of the IMU data would have allowed me to input these to the Kalman filter, and it would really improve its performance. I’m aware I could have built IMU readings into the software myself, but I did not have the time.
-
When I went to merge the Arduino logged positions, the time of recording in the Arduino was different to the processed reach log file points. Took me a long time to figure out, but half the solution is to set a Start Time in RTKPost that matches the start time of your logged data. This at least means the times will start out synchronised. It worked for a few of my recordings, but on some there was a position update that wasn’t at 14hz, and the logs would no longer match up. I started writing some code to re-synchronise the values to their nearest matching time, but again I ran out of time. Just something to be aware of if anyone is having similar problems.
-
Post Processing - I found myself wondering if there is going to be development of a single post-processing program. The current 3 programs are easy to work through, but having 3 windows open to move some file names between seemed less polished than the rest of Reach.
The Thesis PDF is here - 11MB.
Finally, a thanks to @cczeets and @Luke_Wijnberg whose positioning tests I cited in my thesis.