Hi
As the title suggests: “Does ardupilot 4.6.x support RTL without compass?”
As betaflight/inav currently supports this for copter.
It’s good question.
In case of RTL all available direction sources should be used.
Can’t imaging RTL with not work without compass while we can get direction from GPS.
What if the compass fails during flight? Or the cable becomes disconnected.
As compass is quite sensitive and may be interferenced with on small copter, especially FPV drones.
As I have met this issue here: Why magfit's output result is out of parameter range?
And I know bf/inav has got GPS(no compass) working for RTL. Ardupilot has Dead Reckoning Failsafe — Copter documentation and RTL/Smart RTL.
So is there any possibility to intergrate all those methods for graceful degraded RTL.
SmartRTL > RTL > RTL (with compass) > Dead Reconing, bit mask for enable or disable???
1 Like
If your compass fails and you have params setup correctly, the system will fall back to estimating heading off of GPS (which should be stable enough for RTL).
https://ardupilot.org/copter/docs/common-compassless.html#gsf
1 Like
@manavgandhi17 Thanks.
EK3_SRC1_YAW = 3 might be do the work, I set default to 1 (compass, which is NOT good.)
1 Like
Hi @lida2003,
It’s important that the vehicle has a good heading estimate. A single GPS on its own does not provide the heading, it provides the direction that the vehicle is moving in and multicopters can move in any direction.
If a compass fails, the pilot should see a failure message in the ground station and the EKF should have no problem estimating the heading based on just the IMU’s gyros (which drift but very slowly) and it can also make small corrections comparing the vehicle’s IMU based accelerations vs the GPS movements.
If a compass is not to be used at all (even from the beginning of the flight) then we have various solutions including GSF and GPS-for-yaw. This wiki pages has links to the various options.
Hope that helps!
1 Like
From the wiki page shared by @manavgandhi17 and @rmackay9, it’s great to see that there are algorithms in place, and apparently, the code can handle such situations.
What I’m thinking about is whether there is any guide or tutorial that provides tests or examples for achieving a graceful Return-to-Launch (RTL) solution.
As we assemble our drone/copter, we will set it up as optimally as possible, ensuring good conditions for GPS, compass, etc. However, if something goes wrong mid-flight, I want to configure it to handle exceptions—such as an unhealthy compass or GPS signal loss—by switching to Plan A or Plan B, depending on our preconfigured settings.
From what I understand from the wiki, I can set EK3_SRC1_YAW = 8 (GSF) to use the GSF (Gauss-Newton Filter). However, I want the drone to step down through a planned sequence of fallback behaviors, ensuring the best possible response. Is this achievable through configuration, and if so, how can I set it up?
For example, can I configure the drone to follow this priority sequence?
- Smart RTL (if possible)
- RTL using compass
- RTL without compass, using GSF
- Dead Reckoning (as a last resort)
This way, the drone would always attempt the best available method to return safely.
Would appreciate any guidance on achieving this through configuration!
Hi @lida2003,
I think you could write a Lua script to handle a compass failure (during flight) but I don’t think it’s necessary. I think the vehicle will normally be able to complete its mission and even make it home if the compass fails. Compasses almost never fail though. They are badly affected by magnetic interference (normally from the body of the vehicle) but rarely do they actually fail.
GPS failure is handled using the EKF failsafe. You’ve probably already seen it but we have a copter dead-reckoning wiki page here.
I can definitely imagine (and even expect) that commercial drones using AP are put through a series of tests to confirm their behaviour in various failure scenarios. We do not have a consolidated page which talks about all the possible failures and how AP reacts but I think all the info is on the wiki. We’ve also got some auxiliary functions (that can be triggered either by the RC or using MP’s “aux function” tab) that help an operator to test these features in a controlled way. So for example, there’s a “GPS Disable” option. Of course it’s also a good idea to test these in the simulator an Simnet has a Copter failsafe course that is meant to help training operators on what to expect.
1 Like
Thanks for confirmation. If there is no available application for this requirement, then a lua script is the shortest way to integrate those module/functions together.
Thanks, quite a lot of What if 
@rmackay9 I appreciate your time and expertise on this.Thanks very much!
1 Like
Just had it happen yesterday… It was more fun though, the compass with GPS (combined unit) flew of its support never to be found, because one motor mount broke partially causing huge vibrations (a HD camera also dislodged, hanging by a cable!). Somehow I managed to land in grass, but the copter continued to spin props for 60 seconds and saying it was landing… until I smashed the props… (Disarm seemed not to work!)
So never assume anything, if something should never happen, it will!
1 Like
Hi @Michail_Belov,
That’s no fun. Good to hear you got the copter back.
The difficulties disarming are related to the vibration. The normal disarm (with the sticks) has protection against accidental disarming in flight but that check is thrown off by high vibration which can cause the vertical speed estimate to be off. Disarming from an RC aux switch would likely have worked as would disarming from a ground station… all too late to be of any good to you of course but just for anybody reading who might find this useful.
I was very lucky I was doing a test flight, if it were in the mountains, it would have been different story… But now I am reworking the frame, strenthening all motor mounts.
1 Like
And waiting for new set of props to arrive…
IIRC for copters it is recommend to use Arm/Emergency Motor Stop as it doesn’t immediately disarm giving time to recover from accidental activation.
1 Like