What will happen if GPS + RC fails?

[barzanisar]

Hi, What will happen if GPS fails? Which parameter decides GPS failsafe action?

And what will happen if both GPS fails and RC loss occurs? If this happens we can't fly in any flight mode so the logical thing to do in this case would be to land at the current position. Again, which parameter defines this action in this case?

[hamishwillee]

Great question. I have created https://github.com/PX4/px4_user_guide/issues/205 because we don't have any failsafe documentation, and we should.

My understanding is that the GPS failure action is to loiter for a time and then do flight termination (landing process - vehicle specific). The loiter time is defined by NAV_GPSF_LT. Note also that the GPS failure can be disabled using CBRK_GPSFAIL. For RC loss the action is defined by NAV_RCL_ACT.

I suspect that the two conditions are handled completely separately and what happens depends on when each happens. However the end result is likely to be as you have said. So for example if RC is lost and the action is RTL, then if GPS subsequently fails the landing will occur. Could be completely wrong:-)

It is also likely that the GPS loss is now actually interpreted as some sort of EKF position quality fail (ie not GPS failing, but position lock failing). Would be good to get clarification on that?

[barzanisar]

@hamishwillee what you say makes sense. @thomasgubler who should be the right person to clarify this and possibly confirm the failsafe guide that we create in the near future?

[thomasgubler]

Currently we do flight termination: https://github.com/PX4/Firmware/blob/master/src/modules/commander/commander.cpp#L2604

@priseborough I might be wrong. But I did not see immediately that simultaneous RC and GPS loss is already covered in your FMEA analysis table.

[priseborough]

We deal with single failures and then look at the system level responses which vary depending on flight mode, etc. The system level effect on flight in the FMEA states:

Vehicle trajectory starts to deviate. Commander failsafe reverts to a flight mode not requiring GPS that prevents a flyaway. Repsonse mode is platform type dependent and determined by the commander failsafe. Safe flight reliant on operator intervention and manual control.

[thomasgubler]

Did this get documented?

On Fri, Apr 27, 2018 at 2:45 PM barzanisar notifications@github.com wrote:

Closed #9336 https://github.com/PX4/Firmware/issues/9336.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/PX4/Firmware/issues/9336#event-1598690194, or mute the thread https://github.com/notifications/unsubscribe-auth/ABWo12ei37k1tMNAMgLEbo9IG9l2wfEsks5tsxLvgaJpZM4TboZZ .

[barzanisar]

@thomasgubler This will be documented in https://github.com/PX4/px4_user_guide/issues/205 I must have closed this issue by mistake.

@hamishwillee is someone documenting the failsafes https://github.com/PX4/px4_user_guide/issues/205? Or are we waiting for FMEA to get completed?

@priseborough According to @thomasgubler and @hamishwillee, if upon GPS failure, the only failsafe action is flight termination/landing on spot, then I guess there's no need to worry about 2 failures at the same time (as @hamishwillee suggested).

However, what I understand from your comment: If GPS fails, the flight mode changes to an RC controlled mode not requiring GPS. Am I right? But what if RC also fails and the user had chosen RTL as RC loss failsafe? RTL requires GPS. So my suggestion is that there should be a sanity check in the autopilot where it just lands on spot if both modes fail and both modes failsafe actions depend on each other. What do you think?

[priseborough]

I don't know the answer to "But what if RC also fails and the user had chosen RTL as RC loss failsafe? RTL requires GPS." I recommend you inspect the code and run a test in SITL.

[hamishwillee]

@hamishwillee is someone documenting the failsafes PX4/px4_user_guide#205? Or are we waiting for FMEA to get completed?

I have been waiting on this discussion to end. I will probably get to this in the next two weeks, but it is not the most urgent thing on my list.

@priseborough I am probably being stupid, but when you say ...

We deal with single failures and then look at the system level responses which vary depending on flight mode, etc.

Would I be correct in interpreting this to mean that after you get any failsafe you're in a failsafe mode with special system level handling of subsequent failsafe. So whatever the normal failsafe behaviour was for the second failure, it is no longer necessarily what happens

I imagine for MC this would be moving into Altitude mode for GPS failure, and perhaps Land mode for a further battery failsafe? No idea what FW might do! Will be interested to see what you find out @barzanisar :-)

[priseborough]

@hamishwillee That is correct. The handling of subsequent failures for the system is not well defined and is difficult to infer from a code inspection. On one project I worked on there was a requirement to be fail operative for a single failure and another to 'degrade gracefully' for subsequent failures. The latter requirement generated a lot of additional work in testing because of the large number of possible combinations. In the end we only tested combinations where the combined probability was above a threshold.

[hamishwillee]

THanks @priseborough - that is very helpful for the docs.

I can see the challenges, particularly when you throw in the need to support different behaviour on different platforms. My intuitive (read that as "probably incorrect") feeling is that there are some fails that should always force an immediate landing - e.g. battery critical. Anyway, a discussion for another day.

[hamishwillee]

I have created PR for docs that capture the most important bits of this here: https://github.com/PX4/px4_user_guide/pull/212

It does not attempt to cover the detail of "what happens in multiple failsafe situation" other than to say that this is handled separately from normal failsafe behaviour.

Can we/should we close this issue?

[barzanisar]

I tried this special case in simulation with quadrotor. My findings:

I flew in HITL position mode, and then set EKF2_AID_MASK to 0 (to stop using GPS) to initiate " no local position" failsafe. Since autopilot couldn't receive position estimate, according to COM_POSCTL_NAVL, it assumed I had RC and switched to Altitude mode. Next, I unplugged RC to initiate RC failsafe. Eventhough NAV_RCL_ACT was set to RTL, the autopilot landed on the current position (awesome! which is what a user would want).

I repeated the same in SITL but instead of setting EKF2_AID_MASK to 0, I stopped GPS with command "gpssim stop". It again initiated local position failsafe action (same as described above).

When I flew in mission mode in SITL and stopped GPS with "gpssim stop", it enabled "no global position" failsafe (which is GPS failsafe) and landed immediately on spot, even though NAV_GPSF_LT (loiter time before flight termination) was set to 15 secs. From the code, NAV_GPSF_LT seems to be only for the Fixed Wings.

I guess it makes sense to land on spot upon GPS failure in mission mode since the user may not have an RC in hand while flying mission.

My understanding is clear on this.

[barzanisar]

@hamishwillee I guess we can close this issue once the findings above are documented in the failsafe doc.

[hamishwillee]

Thanks @barzanisar . I will close now and think about how to include the above info - I had hoped not to include this sort of thing because we can't be exhaustive.

[hamishwillee]

PS @barzanisar I don't quite interpret the results as you do above: https://github.com/PX4/Firmware/issues/9336#issuecomment-386274299

Specifically, I would guess that COM_POSCTL_NAVL always controls the behaviour. In your HITL tests you had RC and altitude so you changed to altitude mode. When you disabled RC the system switched to no RC available handling and landed.

In mission mode on SITL I suspect you had RC disabled (default in SITL), so manual control was not possible - resulting in immediate landing.

I could be wrong on this - after all COM_POSCTL_NAVL is in the "mission" section, so could only apply to mission position behaviour.

I agree that NAV_GPSF_LT seems to only be for FW. It is not clear when this is applied though.

• Could be only in some modes - ie if no RC before entering LAND mode this might be done first
• Could be immediate - ie before going into whatever failsafe action is, it circles and waits for GPS to come back. We need to find out which.

[IeiuniumLux]

The NAV_GPSF_LT param uses the term Loiter in its description. However, Loiter requires GPS so how (in the case of a fixed wing) will the vehicle hover in circle? Is going into some kind of altitude-hold mode with a predefined safety radius?

[hamishwillee]

@IeiuniumLux Please don't repost against closed issues for support questions. Raise support questions on the forums. That said, the answer to this is here: https://docs.px4.io/en/config/safety.html#position-gps-loss-failsafe - essentially it circles at a fixed pitch/roll/thrust - without having to know GPS

[IeiuniumLux]

Darn it. I failed to notice that it was closed. Sorry about that and thanks for the link with the clarification. Actually, it would be great if QGC updates their NAV_GPSF_LT param description with what you just wrote " it circles at a fixed pitch/roll/thrust", instead of using the misleading Loiter. Cheers!

[hamishwillee]

@IeiuniumLux No worries. The big problem would normally be for you - no one particularly is tracking closed issues so you won't necessarily get responses.

W.r.t. NAV_GPSF_LT the problem is that QGC has limited space for the strings. I'm not sure it would fit the fully accurate description.

Loiter time that vehicle circles at a fixed pitch/roll/thrust while waiting for GPS recovery - before it goes into flight termination.

or the extended version ... :-)

Loiter time that vehicle circles at a fixed pitch/roll/thrust while waiting for GPS recovery - before it goes into flight termination. Assuming RC is available, otherwise termination may occur immediately. Also if another failsafe has happened first, the behaviour is system dependent, but is probably to land or terminate (crash).