This is a lightweight RTK receiver coming in at about 60g including a 750mah battery, would be less without. Make from a Raspberry Pi Zero 2 W, with a U-Blox M8T receiver and a Beitan BT520 antenna. Stuck in a 3D printed housing and attached with dual lock. The total cost of doing this is about £200, you can do it for cheaper if you scrounge parts, it cost me about £100 as I bought the GNSS IC seperately and soldered it to a cheaper protoboard than what is commercially sold.
You do also need a base station to provide the corrections, thats a whole other kettle of fish but at a minimum you need a second set of everything above. I’m using a higher grade antenna (Trimble Zephyr Geodetic) but the same receiver (M8T). I use RTKLIB for all my post processing
Flew it for the first time and a few things came to note:
The Mini 3 Pro didn’t care at all about the extra weight, the extended battery is an extra 40 g so this is another 20 g more than using one of those, much in the grand scheme of things but still almost 10% of the total mass of the drone. Motors a little warm after flight, but I had been zipping around in sport mode.
Airdata reckons this cuts the flight time down to 20m, again it’s probably not as severe as I spent some decent time in sport mode.
Now for the figure, Yellow is the GNSS from the Mini 3 Pro (via. airdata), Red is the post processed kinematic data from the external module.
Firstly, it’s worth saying that the inbuilt GNSS does impressively well here! You can see it lags behind a bit in the turns as the internal ‘model’ is catching up most likely. The heights are pretty close as well, although it has the advantage of aiding though all the other onboard sensors.
The external receiver performed ideally with a 97% fix rate. Hopefully this weekend I can get out to scan something and see what the performance difference is in photogrammetry, which is the only real use for this.
Only issue that still exists is how to input offsets for the external antenna, as you need the heading data to correct for position at the sensor. For any commercial advantage, this would be essential. I could probably script something to take the Air Data log to compute the offsets with the internal heading.
Correct, however over short ranges the black box can transmit and receive over WiFi. For now it’s not doing any real time corrections on the chip either as its easier to check the quality by doing it in post.
However… This is the same manufacturer of chip that DJI (and to be honest almost all small integrated GPS chip users) use.
There is no particular reason (short of having to tear the drone apart) that you couldn’t hijack the coms line for the internal chip and feed in the corrected data, as well as tapping into some internal 5v supply for the power. There just isn’t much benifit as its just as easy to location tag stuff with exif tool after the fact.
Later in the year I’ll be adapting this for a self build, at which point I can do the corrections live over radio
I think the difference would be marginal as I get the inkling DJI don’t feed ‘raw’ location into the log files and are using all the extra sensors to generate a sort of smoothed inertial location given how close the two traces are.
My other concern feeding the data in would be if you drop the RTK solution, for example fix to float is about a 10 cm jump, float to single (e.g if you loose the corrections) is a few meters jump, and I don’t know how the internal position model would handle that. Having said that the P4PRTK and the Enterprise RTK must both be able to deal with that and I imagine its all the same underlying code.
That’s right, you’re an expert. I have been using P4RTK for a long time. I only bought it for measuring small aircraft with high precision, but the price is too high. TopoDrone’s service is also poor, often dodging to answer my questions,
If you make a large number of such devices, I believe many people will be interested. TopoDrone’s technology mainly uses cables to capture camera signals, and it cannot be installed on any model.
Hi
Is there are any possibility to share your project details
Or if you can provide Kit with details , much bettor for community, who interest for RTK and PPK (I am wiling to pay for the Kit and details _
I haven’t made the 3D print files public, just because they aren’t quite right at the moment.
There’s no bespoke code running, it all runs off RTKLIB for which I’d recommend reading rtkexplorers blog on how it works with low cost receivers. A bash script on the boot on the nanopi starts RTKLIB though the command line, this logs to the SD card, and transmits the raw GNSS data over TCP on the WiFi for monitoring if you have a signal, I’ll dig it out so you can see what I mean at some point.
If I wanted to spend a bit more money, I’d recommend the ZED F9P over the M8T, but it’s also heavier so might not work as well weight wise.
Hi
Really appreciating your knowledge sharing and quick response.
In the meantime can you elaborate the method you integrate with Mini pro please ? (cable connections and pinouts etc.)
Hi, there’s no integration, it is a standalone module so the processing must be done in post.
I use exif tool for this to update the geotags for the photos. The big issue is time sync between the drone and the controller, as it uses the mobile devices time which is often out by a few seconds. Taking a picture at the start of a GPS time synced clock can tell you this offset.
Unfortunately I don’t have the financial freedom to start tearing apart mini3’s to look at hijacking the drones own GPS. But I’m sure it could be done as I belive dji use Ublox chips as well
In theory, at some point in the chain you could MOTM it to just send your own message. The drone shouldn’t know any difference. DJI have used the same chip (or varient thereof) for years now, so if it works on one it would work on the others
The nanopi would generate the solution, so you’d still get a GPS signal without the RTK as well, and just forward it to the controll MCU on the drone. If you wanted to be really fancy you could probably engineer a fallback to the internal if you lost signal from the nanopi for extra Saftey.
I mean if you wanted a mega slick implementation you could try and transplant a f9p chip which has an RTK engine in it straight into the drone…
