I have been testing the mobile takeoff and landing function recently. During the testing process, I encountered an issue. According to the official documentation, to implement mobile takeoff and landing, two flight controllers are required: one flashed with rover firmware and the other with plane firmware, and the follow function is used to achieve mobile takeoff and landing. However, I am unsure how to implement RTK high-precision positioning simultaneously. As we all know, RTK typically requires a fixed base station. But on a ship, it is impossible to remain stationary. Additionally, Network RTK is hardly feasible because there is no network coverage in most marine areas. Therefore, to achieve both mobile takeoff and landing and RTK high-precision positioning, the only solution I can think of is using a portable reference station (mobile base station). However, I am not certain if this approach is viable.
The GPS module of the ground flight controller, such as the UM982, not only provides position information to the ground flight controller but also acts as a base station, transmitting real-time RTCM data to the UAV. In fact, I have already conducted tests using this method. In Mission Planner, both the ship’s and the UAV’s positions show “RTK Fixed,” and the UAV’s home point continuously follows the base point—yes, the base station is mobile. However, I can’t help but feel there are potential risks involved. I cannot guarantee the safety of this setup.
Technically, you get a precise baseline between the base and rover. You only get an accurate global position if your base has a known accurate global location already. So normal baseline setups have a fixed base at a very well surveyed location, and rovers that compute good RTK solutions against that have centimeter level accuracy with respect to the global frame because of the precise computed baseline respect to each other.
In a moving baseline setup, the moving baseline base (mb-base, the one that sends the corrections) and moving baseline rover (mb-rover, the one that receives the correction and computes the baseline, and not to be confused with ardupilot rover) have high precision baseline with respect to each other (in the body local coordinate frame of the mb-rover), and a more accurate global position than an autonomous solution alone. This is also why RTK for Yaw can be used on relatively small craft and remain mostly usable for yaw.
One way to approach this problem is to log the baseline vectors you get from the rover and see how much they vary, for instance by converting them to PLND messages for recording.
Additionally, I asked Leonard Hall about this in discord, you might find it illuminating Discord , and he doesn’t use RTK, just two independent autonomous solutions
There’s also this wild study that used RTK (with a local fixed base) to do a high speed landing on a moving target.
I think this is a potentially excellent use case for moving baseline.
Folks tend to get caught up regarding global accuracy vs local precision. As Joshua points out, you get outstanding precision between the moving base and rover in such a scenario. The global accuracy will only be as good as non-corrected GPS. So long as that meets needs, there is no reason to fret about it.
I do think vertical positioning via solely moving baseline reference could be problematic, so recommend the use of a rangefinder for the endgame touchdown.
I’d love to hear why you think this is so, I’ve been gearing up for a test that will exercise this. Unless it’s just more of “vertical precision in gps is the worst of the dimensions” no matter how you spin it?
And as an aside, I am not seeing support for passing the vector back out of a GPS driver (at least in copter) so work would need to be done to expose the message for use in the AP, like for instance to inform PLND. There is clear prior art for sending the correction messages over mavlink (but I’m not sure if that is in rover/boat, just in MAVProxy), but I am not seeing how to make use of the resulting baseline without hacking a driver. It is on my list of things to try out at some point though
A combination of your statement regarding the worst dimension and some historical (somewhat anecdotal) evidence that GPS as a sole or primary altitude source, even corrected, can behave a bit poorly with ArduPilot. But most importantly, RTCM3 is typically sent at 1Hz. If the moving base is pitching on a shipdeck, its vertical position is likely to change in 1 second. Depending on how precise the landing need be, a rangefinder could mitigate that.
You don’t necessarily need the calculated vector from within the GPS driver. The relative position is enough, I should think.
I’ll need to reread the high speed landing paper, I think that the aircraft was mostly full tilt forward and wasn’t using a rangefinder and could make it down, but I guess the landing platform isn’t heaving since it’s a truck on a nice road. And Leonard’s test was on a big ship at what looked like calm enough seas. I am eager to get data and run these kinds of tests
Some of this depends on the exact method of recovery. If you’re expecting to flare and land normally, you’ll likely need a high degree of precision. If you’re using some sort of capture method (a net, for example), there may be a higher margin for error.
Thank you all very much for your responses.I have sought various help online, and someone seems to have made it work. They told me that it mainly depends on whether the GPS has this function. I conducted tests according to their advice. During the tests, the EKF showed a brief red alert, and Mission Planner displayed the following messages:
2025/12/5 15:42:05 : AHRS: EKF3 active
2025/12/5 15:42:05 : EKF3 lane switch 1
2025/12/5 15:42:03 : AHRS: DCM active
When I checked the flight log, I found that EKF3.IPE (note: it may be a typo of EKF3.IPE, assuming it refers to EKF3-related position error parameter) had abrupt jumps—12 meters during takeoff and 18 meters during landing respectively. As I mentioned earlier, even though my UAV already showed “RTK Fixed”, I still have doubts about its safety. Therefore, I hope someone can tell me the feasibility of this solution. Only then will I consider its accuracy.
The UAV already shows “RTK Fixed” on Mission Planner, but I noticed that if I don’t power off the UAV, it still displays “RTK Fixed” even when I restart the relevant equipment or disconnect the RTK signal. Moreover, during my actual test, the following prompts appeared:
2025/12/5 15:41:53 : Transition started airspeed 6.1
Therefore, I maintain doubts about its safety. I’m very sorry, but I’m still a novice in UAV operations. I need someone to tell me the feasibility and safety of this solution. Additionally, I want to know: is the accuracy of mobile takeoff and landing sufficient even without using RTK?
The only person who can answer that question is you, since we don’t know your hardware and haven’t seen any of your data, and don’t know your requirements.
Instead of having us guess, consider what data you would need and find a way to collect it.
The rover GPS takes a bit to stop reporting RTK Fixed after the last correction is received. I don’t know the exact criteria, but I’ve noticed it can be up to about a minute in some circumstances.
A GPS solution is an exercise in estimating the constellation of the satellites and in many cases using a fusion algorithm to estimate your position with respect to the constellation given your own local movements. RTK improves this estimate by using another receiver’s notes. If you have a good RTK solution, you’ll be able to maintain it for a short time after losing those notes before the error grows too large, similar to how IMUs can dead reckon for some time after GPS loss. The growth of the error over time depends on your local movements, quality and capability of the hardware, and quality of the solution.
Thank you very much, you’re absolutely right. I will continue testing this function later. It seems I made a mistake—I posted this in a regular fixed-wing thread, but my UAV is a VTOL (Vertical Takeoff and Landing) fixed-wing. My primary goal is to achieve maritime RTK positioning for precision landing at sea. However, the aforementioned prompts appeared during the test, which has made me a bit anxious.
VTOL makes the entire problem a lot simpler. In fact, if the deck is large enough, you may not need cm level precision at all. Conduct some testing with your specific hardware and aimed toward your specific requirements.
Not only is my goal to achieve mobile takeoff and landing on ships, but also to realize RTK positioning at sea. However, it’s basically extremely difficult to find reference cases online, which makes me quite anxious.
When I tested with a regular GPS, I never received such messages as “AHRS: EKF3 active”, “EKF3 lane switch 1”, or “AHRS: DCM active”. Therefore, I’m very concerned about the subsequent tests.