Inav: You can arm with a navigation mode selected when nav_launch is enabled.

[MrD-RC]

Current Behaviour

If you try to arm with a navigation mode (RTH, Loiter, etc) selected, iNav will deny the arm until you have switched to a pure flight mode.

If you have nav_launch enabled, either by switch or permanently enabled, iNav will allow the arm regardless. This is bad, as it is not consistent with standard arming procedures. Therefore people can inadvertently have a navigation mode enabled, launch unaware of this, and it could lead to a crash. A friend of mine had this happen. They accidentally had RTH enabled, auto-launched the plane which was going to fail. They tried to pull up to save the launch. Instead, it activated RTH and the plane crashed.

I completely understand that you can select nav modes to come in after the launch completes. If you try to correct a failing launch, it will still crash. That is fine. However, they should not be able to be activated until after the arm. This ensures the pilot knows what mode they are launching in, and it is consistent with standard arming procedures. I'm sure that no one will knowingly enabled a nav mode when setting up and tuning nav_launch. This will also protect those pilots.

Steps to Reproduce

1. Enable nav_launch (or have it permanently enabled)
2. Switch to RTH
3. Arm

https://youtu.be/1laiR6mr07I

Expected behaviour

iNav should not arm, and you should get a message on the OSD stating "Unable to arm - Disable navigation first"

Suggested solution(s)

Do not allow arming when a navigation mode is selected.

• FC Board name and vendor: Any - Mine is INAV/MATEKF405 2.5.1 Jun 16 2020 / 12:41:44 (098a574b3)
• INAV version string: GCC-9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label BUG to this issue, with a confidence of 0.92. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[avsaase]

The nav launch sequence is:

1. Enable nav launch (if not permanently enabled)
2. Select mode for after launch is completed
3. Arm
4. Raise throttle stick
5. Throw airplane

If you have launch mode permanently enable this is perfectly consistent (although I am not sure what happens if you are in a navigation mode but disengage launch move before raising the throttle by wiggling the elevator stick). But I can see that if you have it on a stick then the ability to arm into a nav mode when nav launch is enabled may seem inconsistent. I think the simple solution is to switch 2 and 3 in this procedure. On the other hand, you could argue that nav launch is a navigation mode in and of itself so you are already arming into a navigation mode anyway.

[MrD-RC]

Regardless of whether or not nav_launch is permanently enabled or on a switch, it is inconsistent with arming without nav_launch. You should not be able to arm with a navigation mode selected. This inconsistency can cause issues, and crashes. I know people who have experienced this.

The correct sequence should be:

1. Enable launch (if not permanently enabled)
2. Arm
3. Select navigation mode for after launch complete
4. Raise throttle
5. Throw plane

[avsaase]

My point was that when you have nav launch permanently enabled you cannot arm without nav launch so it is consistent in the sense that no matter what you do, you _can_ arm with a navigation mode enabled. At least for me this is why I never noticed any problem. I do see you point, though.

[MrD-RC]

Ah yes, thats true. If you have nav_launch permanently enabled it would be consistent, because you are only ever arming with launch mode active.

But surely that just means that the bug need fixing more so. To make it consistent with non nav_launch arming.

[breadoven]

Defined in Navigation.c. controlled by "navLaunchComboModesEnabled". Sensibly it doesn't allow Launch with with PosHold set. Could argue RTH is similar during a failed launch with the difference being it will TRY to climb to whatever the RTH altitude setting is, could be TO altitude for some settings.

navArmingBlocker_e navigationIsBlockingArming(bool *usedBypass)
{
    const bool navBoxModesEnabled = IS_RC_MODE_ACTIVE(BOXNAVRTH) || IS_RC_MODE_ACTIVE(BOXNAVWP) || IS_RC_MODE_ACTIVE(BOXNAVPOSHOLD) || (STATE(FIXED_WING_LEGACY) && IS_RC_MODE_ACTIVE(BOXNAVALTHOLD)) || (STATE(FIXED_WING_LEGACY) && IS_RC_MODE_ACTIVE(BOXNAVCRUISE));
    const bool navLaunchComboModesEnabled = isNavLaunchEnabled() && (IS_RC_MODE_ACTIVE(BOXNAVRTH) || IS_RC_MODE_ACTIVE(BOXNAVWP) || IS_RC_MODE_ACTIVE(BOXNAVALTHOLD) || IS_RC_MODE_ACTIVE(BOXNAVCRUISE));

    if (usedBypass) {
        *usedBypass = false;
    }

    if (navConfig()->general.flags.extra_arming_safety == NAV_EXTRA_ARMING_SAFETY_OFF) {
        return NAV_ARMING_BLOCKER_NONE;
    }

    // Apply extra arming safety only if pilot has any of GPS modes configured
    if ((isUsingNavigationModes() || failsafeMayRequireNavigationMode()) && !((posControl.flags.estPosStatus >= EST_USABLE) && STATE(GPS_FIX_HOME))) {
        if (navConfig()->general.flags.extra_arming_safety == NAV_EXTRA_ARMING_SAFETY_ALLOW_BYPASS &&
            (STATE(NAV_EXTRA_ARMING_SAFETY_BYPASSED) || rxGetChannelValue(YAW) > 1750)) {
            if (usedBypass) {
                *usedBypass = true;
            }
            return NAV_ARMING_BLOCKER_NONE;
        }
        return NAV_ARMING_BLOCKER_MISSING_GPS_FIX;
    }

    // Don't allow arming if any of NAV modes is active
    if (!ARMING_FLAG(ARMED) && navBoxModesEnabled && !navLaunchComboModesEnabled) {
        return NAV_ARMING_BLOCKER_NAV_IS_ALREADY_ACTIVE;

[MrD-RC]

To me, only blocking poshold is not right. RTH should also be blocked as if climb first is not enabled it will just try to circle. Which could either just crash, or fly back at you (which I assume is the reason poshold is blocked). In reality, the arming blocks on nav_launch should be the same as the standard arm.

This does not effect how you can use nav_launch, only the procedure. Once armed, you can set the mode to RTH, loiter, whatever you want. But it also adds safeguards to stop arming in a nav mode when you don’t realise that you are in one. Personally, on a model that I know is flying and launching well, my procedure is:

1. Enable launch
2. Arm
3. Set mode to poshold
4. Raise throttle
5. Throw.

My aim isn’t to limit the functionality. It is to add a safeguard that is consistent with the regular arming procedure in iNav. As I know people that this has caught out.

[avsaase]

I agree that arming into any nav mode should be blocked for the simple reason it causes an inherent contradiction: in the nav modes the aircraft is flying itself, but at the moment you arm the aircraft is not flying at all.

I also agree with the new procedure, but the downside of changing the procedure is that a lot of people already struggle getting the current procedure right. While the change you propose does not make the procedure any more complicated, it is different to all the youtube videos, facebook posts, etc. that explain the current procedure, so there will be a lot of incorrect information out there. Not saying this is a definitive reason not to change things, just something to consider. You also need to consider that the group that uses nav launch, but does not have it permanently enabled is, I think, relatively small.

[avsaase]

I think some answers to your poll today in the INAV Fixed Wing Group raise another reason not to change the launch procedure. Apparently some people like to put nav launch on the same switch as pos hold or rth. That would not be possible with the proposed change.

[breadoven]

Well you could just remove navLaunchComboModesEnabledand set the Nav mode after Arming and it would work OK from what I can see (Launch overrides all other Nav modes so they won't kick in until Launch completes). However, it might be useful to understand why navLaunchComboModesEnabledis there in the first place, not immediately obvious why it's needed.

The alternative is to inhibit the preset Nav mode from starting until the Launch has completed based on nav_fw_launch_timeoutor nav_fw_launch_max_altitudesettings. It is also considered completed when the sticks are waggled but that wouldn't help for a failed Launch where you're trying to use the sticks to save it. And you'd have to reset the Nav mode to get it working again. Starts getting a bit messy.

[MrD-RC]

@breadoven Its exactly the failed launch example that brought this error to my attention. They had nav_launch permanently enabled. Then they edited their model, and inadvertently put RTH on the arm switch channel. They attempted a launch, which was failing, so they attempted to take control and RTH kicked in. They also use RTH with climb first disabled, so it started circling around towards them.

I too don't understand why navLaunchComboModesEnabled was added? Just using the standard check would have been fine. Then set the flight mode after arming. It would be interesting to hear why this was added. I think the best solution would be to remove it.

[MrD-RC]

@avs2 I actually disagree. Firstly, only 4 people have said they do this out of 136 (currently) votes. So a tiny percentage. Out of those 4, 2 of them would not be effected as they have it in combination with Angle or Acro, which are not navigation modes.

I think the poll is pretty interesting, and it would be great if there are a lot more responses. But so far, it looks like nav_launch on a switch is the most popular option.

I also took in to consideration what you said about the YouTube tutorials on how to set up nav_launch. I decided to check out the top results when searching for inav autolaunch setup on YouTube. Most of them didn't even mention setting a post launch flight mode (including my own video facepalm and Paweł's). Those that did all varied. The only constant was that it was after activating nav_launch but before throwing. Before arm, after arm, and even after raising the throttle were all suggested. So as far as tutorial video go, there is no definitive correct way for the procedure.

I honestly see nothing to stop the change. Especially with the added safety and consistency it brings.

[avsaase]

@breadoven Then they edited their model, and inadvertently put RTH on the arm switch channel.

If you make this mistake then you are screwed regardless of the launch procedure since you cannot disable rth without disarming. Even when you do have a correct setup, having a launch mode selected for after nav launch will be a problem when the launch fails, if you are not quick enough to switch back to acro or angle once you see the launch is not going well.

I think you are right, the launch procedure should probably be changed.

[MrD-RC]

Totally agree @avs2. However, the standard arming procedure would have highlighted that RTH is enabled. It would have no doubt been an annoying problem to work out what's going on. But at least they would have been alerted to the problem.

[a1axx]

Im that guy!

I was convinced to try auto launch. When checking out channel tabs I was going to set auto launch to a switch, I changed my mind and cancelled it. I dumb thumbed and turned rth off, but immediately turned it back on. It was bright in the field, I didnt see that cancelling and opening RTH in the tabs changed it from CH7 - CH5. So it was on my Arm channel.

I armed, launched, the settings were not going to safely get the plane in the air. Manually took over, which then immediately put the plane into RTH, it banked and cartwheeled into the ground.

I disabled auto launch as I just never want to risk that failing to safely launch the plane, and I don't want to play with the settings and make it crash for another reason.

After disabling autolaunch always on, the aircraft would no longer arm for 'disable nav mode' as RTH was on.

I was not satisfied the behaviour is right.

If people want to arm and auto launch into a nav mode ie launch to loiter, I believe they should just flick that switch after arming, then throttle up and launch