Wow! Nice work. Would love to hear more about your setup and workflow if you want to share.
Just running a couple more proving flights at the moment. One of my test areas is an archery range with very convenient GCP’s. I went out this morning and did the GCP survey, with each point being accurate to +/- 1cm RMS. PLotted them against the low resolution (will run the high accuracy processing tonight) Pix4D orthomosiac.
See attached image. I am very please with the results you will see little white diamonds on the ground and in some places little yellow diamonds. The yellow diamonds are the GCP’s plotted on the mosaic. YOu will need to open the image to full resolution.
Biggest discovery to date has been the drift in the altitude in the Phantom4 as the platform heats up during a flight. It makes a 3metre difference to altitude!
At the moment, you can only change the time system by editing the onboard RTKLIB config file. The path is
/usr/bin/RTKLIB/app/rtkrcv/rtk.conf, the option is
out-timesys. I don’t really think this is needed in the interface, because, as you pointed out, it is configurable during post-processing.
perhaps however the default output for the pos (LLH) files should be UTC as no one I know uses GPST unless they are processing RTK. Users of the position data think in UTC without the 18 sec offset!
@Simon_Allen this is amazing! To be clear, maybe lenguage is giving me the wrong idea here… You used 1 Reach Module onboard the Phantom 4 just to geotag the images, not for flying (I guess DJI has proprietary software/algorithms/etc and can´t be messed with or really hard to). If you don´t mind, what hardware modifications did you do? If I understood correctly this changes my plans on building a quad, I´ll just upgrade to P4P! Thanks and keep the updates coming!
I have built a standalone module (140 grams) that fits under the battery, it is held in place by a tight fit and two tie wraps.
I collect reach data and post process for RTK with base data collected b a second reach (standard post process RTK)
I use the log file from map pilot to get the timing of the images taken (this is where I am currently looking for further improvement)
Biggest find to date is that the Phantom 4 altimeter warms up and the drone drops 3-4m over a 10 minute flight. the DJI altititude stays constant, but the RTK altitude decreases. This is verified on landing, when the drone lands the DJI altitude is 3m above the ground whereas the RTK altitude returns to ground level.
The level of integration and sheer capability of the P4 made me go down this route was mostly happy with the standard GNSS onboard, but PPK is a true differentiator on a very low cost drone ( I picked up a refurbished P4 for AU$1000).
Simon thanks, this is really interesting. Now that you mention it, maps were always “tilted” somehow, maybe that altimeter warming up has something to do, will review… Keep them coming, some of us are learning a lot thanks to guys like you. Aussie aussie aussie, oi oi oi!
This mission was recorded with Pix4DCapture, I have just extracted the time, image number and DJI Latitude, Longitude and Altitude from the json file. Longer flight than the last. Same problem. Same solution.
I will reluctantly increase the size of my groundplane to get better early flight RTK.
I’m interested in how you attached the reach to a phantom 4 drone. I’m also interested in how you collect the reach rtk data (is this at a pc?), and then match up the timestamp of the photo - I’m not familiar with what you mean by using the log files of the map pilot - is that a android or iOS app?
I’m working on a project that is a bit similar.The idea is to pass rtk data to an android app that in turn is used to trigger a photo at a rtk coordinate on a phantom 4 pro.
Wow, I prefer KISS projects (keep it simple stupid).
With the footprint of the photo what is the benefit of passing RTK data down to the app and triggers back up? There is a lot of lag in that. The GNSS receiver on the P4 is pretty good (if you don’t overshadow it with the ground plane of the reach antenna), good enough for taking the photo, but not good enough for accurate orthomosiacs with no GCP’s. And it turns out (due to a thermal issue) no good for accurate elevation maps without GCPs and some form of reference correction.
MapPilot is an iPhone app made by MapsMadeEasy. It produces a fairly comprehensive log file.
In this use case we do not mind the complexity of taking the rtk info from the reach modules and then resending that information back out to the phantom 4 pro.
The point of all this is to use the rtk info and process the information in real time and so provide the phantom 4 with rtk as it flies. As you eloquently pointed out - this is a much cheaper solution than purchasing something like a m200 with d-rtk. .
So as an example, as the rtk information streams into a pc (I assume), we can capture the RTK positioning and then send that information back out to the phantom 4 pro - assuming we can adjust for the lags - we should be able to trigger the camera at a known rtk position or perhaps adjusting loss of altitude as the phantom 4 flies along.
Thanks for your reply.
You have me intrigued.
There are two ways you can do this:
1: mimic the DJI GNSS unit signal and just feed reach RTK in at that point. I haven’t gone down this route. Emlid could if they provided the DJI conformant GPS output just as they do with the ERB. If it makes sense for them to do it (i.e. they see the market is big enough) they may.
2:Use a ground base unit to actively provide autopilot functionality using the DJI virtual sticks otherwise you will be uploading revised missions on the fly with minimal GPS to RTK corrections in them, which is flaky at best. The lag is going to be an issue, but not insurmountable and you will have to use predictive time based image capture commands. Unless you know how to get the onboard SDK into a phantom, in which case, do tell…
#1 - This would be great but that is outside my competency.
#2 - We plan on currently going the DJI virtual sticks at this time. I agree that revised missions will not work. Also there is no way to use the onboard sdk on a phantom which is fine. It is a different cost structure to use the m200, onboard, d-rtk solution anyway.
Let me know if you are interested in something like this. There will be plenty of beta testing if this look promising.
Unfortunately this will not be enough, even if the autopilot has RTK coordinates it will just put nearest one in EXIF. At 5Hz update rate and when flying at 10m/s your picture can be anywhere within a 2m distance during which the GPS update happened.
Thanks for that
You are right at speed. But the way I see this request is more about having absolute positioning accuracy on the drone. IN hover for example the RTK would make the drone very solid.
Hi Simon. With what accuracy did you end up? Vertical and horizontal? Just to understand correcly, both the phantom and Reach get their time from the satellite? (I thought the drone might sync with your device/phone/ipad`s time). But then the only problem is that the time “zones” differ from the 2 devices? How do you actually sync the photos and coordinates? I thought of writing a small program that will just run in a loop and add every photos name next to the coordinate in a txt file. That in turn should be up-loadable to Pix4d in the “add EXIF” section.
Here’s an update.
It has been a bit windy this week so I I have focused on timing. A bit of soldering and a bit of programming and I have trigger for the reach that is synced with the DJI photo to a timing accuracy of about 30ms. It is difficult to be more precise than that as I have yet to find a millisecond clock to take photos of. With my reach results in UTC and with a 0.1 second UTC clock in the image my reach time marks, with a predetermined offset, will get the time right in the displayed clock 98% of the time.
30ms equates to an along track error of 15cm at 5m/s. Couple this with post processed kinematic GPS accuracy of say +/- 10cm horizontally and + 20cm vertically and the error budget looks like …
along track +/- 25cm
cross track +/- 10cm
Vertical +/- 20cm
The workflow is bitty and my electronics appalling, but if anyone is seriously interested in this then e-mail me firstname.lastname@example.org. I assume that my method of timing is similar to that which Sentera do to tie in their IR camera, but my method does not involve opening the drone and of course provides post processed kinematic accuracy on a DJI Phantom. Of course now there is a trigger then it can be used to activate additional cameras.
Just thought I would share and update.
Reach unit mounted on Phantom 4. I ran two missions (at different altitudes, hence slighly different lines) , the second mission was fully FIX and I successfully captured the Phantom 4 photo-timing signal onboard the reach for both missions. This allowed me to inject the PPK positions into the EXIF headers of the images prior to processing in normal photogrametry software.
Big excitement for me is that this is now a fully automatic process rather than a mandraulic data shuffle.