I’m using a camera drone to do a photogrammetric survey of an area. Currently, I’m experimenting with RTK to increase the precision of the georeferencing for the images. To estimate the expected gain, I did the following setup:
I start the drone and wait until the RTK fix is established and a home position is acquired. Then, I take of, fly a few metres away, invoke RTL and check the deviation of starting and landing place.
The results so far have been underwhelming. There is virtually no difference between flights with RTK and 3D fix.
My Questions:
What can be the cause of these deviations and how can I further debug them?
I heard that tweaking the parameter EK2_POSNE_M_NSE can force the EKF to favor GPS measurements over everything else, but I also heard reports of crashes due to normally harmless GPS glitches. What is your standpoint regarding this parameter?
Also, is my test setup working at all or is it flawed in some way? Note that, in the end, I don’t really need precision landing, I just need precise position reports during flight.
About my setup:
My drone has a companion computer (cc) with internet access. The cc now runs mavproxy with the NTRIP module and feeds the received corrections to a CubeOrange via the USB serial port.
As NTRIP caster I used SAPOS, which is a positioning service operated by the german government that maintains around 270 reference stations in germany. It’s high precision service (HEPS) claims to offer a precision of 1-2cm.
Example flight logs are here (with RTK) and here (without RTK).
In my experience, RTK float is problematic and less stable than a normal 3D fix. Furthermore, if you don’t fly for long, the absolute positions in the 3D fix are less accurate than with the RTK fix, but if you land again immediately, you may have the same satellite constellation as at take-off and therefore only a relative coordinate shift.
Older RTK receivers from M8 family struggle with getting and maintaining RTK fixed lock. This may be the cause of poor performance if you are running one of those.
The line slopes between timestamps of reported status. So it goes from 5 to 6 in 200ms, and that 200ms period shows a slope. It’s an artifact of the graph display.
5.39 is the mean (average) over the entire displayed timeframe, meaning that it spent more time at 5 (RTK Float) than 6 (RTK Fixed).
They seemingly do, I didn’t realize how big differences between different modules can be.
I just came across this post, comparing an M8P to a F9P module.
Looking at the prices, the Here4 is sold for almost the same price as the Here3+ (august 2024). Could one conclude that it makes no sense to still favor a Here3+ over a Here4?
Certainly I wouldn’t ever favor a Here3 over a Here4, but I hesitate to recommend a Here4. It uses a Neo-F9P, which is inferior to the Zed-F9P and only as performant as the Unicore UM98x that some other comparably priced modules use, and it has been plagued with firmware issues.
Have a look at the Holybro F9P and CUAV H-RTK series as potential alternatives.
That’s not to say the Here4 is objectively bad. I just think there are alternatives that will likely suit most users better, at least in the near term.
When you try the ZED-F9P, you will realize that using the M8P is a waste of life. ZED-F9P is an epoch-making performance improvement compared to M8P. M8P has almost a small chance of entering RTK FIX.
Thanks for the tip.
What exactly is meant by “performant” in this regard? Will it be notably less reliable at calculating and holding a position? That is, so notably that it justifies the higher price?
The Here4 includes a suite of additional sensors that could technically be used to transform it into a minimally featured but fully functional autopilot. To date, I have not seen an implementation of that. However, that additional hardware adds cost that is of (at present) zero benefit to most users.
You can get a Zed-F9P based GNSS module that is comparably priced and likely more performant (as evidenced by the linked topic).
UM98x based hardware performs quite well (roughly the same as the Neo-F9P, depending on installation, configuration, and exact hardware architecture), typically at a slightly lower cost.
In any case, what you saw out of the M8P based module is typical of its performance, and any of the options I’ve mentioned so far would make a vast improvement. Unless you have an extremely well tuned Copter and very rigorous testing methodology, it’s unlikely that you’d discern a practical difference between any of the F9P or UM98x variants. Choose one that fits your budget and form factor requirements.
