check for safehome when wp mission RTH occurs

[tonyyng]

Corrects behavior reported here: iNavFlight/inav-configurator#1231 (comment)

[Jetrell]

Just to confirm, you used safehome_usage_mode=RTH in your flight, correct? If it was RTH_FS, the mission RTH should go back to the arming point.

@tonyyng I had safehome_usage_mode = RTH_FS with both quad and plane. Also be aware that waypoint missions can be performed with and without an RF link.

I've been using @stronnag builds for testing. But they are built after a merge. @tonyyng my test plane will require target MATEKF411_SFTSRL2

Thanks

[tonyyng]

@tonyyng I had safehome_usage_mode = RTH_FS with both quad and plane. Also be aware that waypoint missions can be performed with and without an RF link.

If you are using mode RTH_FS, I'm pretty sure RTH at the end of a mission will go to the arming point, not the safehome.

I've been using @stronnag builds for testing. But they are built after a merge. @tonyyng my test plane will require target MATEKF411_SFTSRL2

@stronnag, can you build the appropriate version for jetrell?

[Jetrell]

@tonyyng Does that means there will be a limitations in the way Delay Safehome usage mode can be used. Between normal flying and waypoint missions.

The edge case I was thinking of. Is running an automated waypoint mission without an RF link. That would require RTH_FS to be selected so the craft would land or loiter around the safehome.
If your not aware of it. failsafe_mission = off
If this is set, failsafe procedure will not be triggered and the waypoint mission will continue to the end.

Here is the PR for Continue Mission on FS - #4731

[tonyyng]

@tonyyng Does that means there will be a limitations in the way Delay Safehome usage mode can be used. Between normal flying and waypoint missions.

With safehome_usage_mode=RTH_FS, the safehome will only be used for failsafe conditions. I think this is true of "normal flying" or waypoint missions. However, I have not tried it.

I'm not sure how it will work with failsafe_mission = off. I'm not familiar with that logic.

[stronnag]

@stronnag, can you build the appropriate version for jetrell?

Attached to this comment.
inav_3.0.0_MATEKF411_SFTSRL2.hex.zip

[breadoven]

I'm not sure how this will fix this issue with WP missions. The problem isn't finding a RTH Safehome, that will have already been done when you armed before the flight with any Safehome found remaining valid regardless of what happens during the flight because it's related to the home position and nothing else. It shouldn't be changed during the flight because on a long mission you could end up selecting a different Safehome unrelated to the original arming position.

This problem is caused by the fact WP mission uses its own method for RTH that does not set the NAV_AUTO_RTH state flag when the RTH phase is active during a mission. Therefore Safehomes doesn't see WP mission RTH as a "normal" RTH because it's looking for the NAV_AUTO_RTH flag, which doesn't get set.

This could of course be resolved more effectively by implementing #6524. This uses the normal RTH method during a WP mission which means the NAV_AUTO_RTH flag gets set keeping Safehomes happy in the process. Failing that it would be better to add a check that the WP Mission RTH phase is active using posControl.waypointList[posControl.activeWaypointIndex].action) = NAV_WP_ACTION_RTH in selectNavEventFromBoxModeInput.

[stronnag]

@breadoven. Are you content that #6524 is complete and working? If so, let's merge it.

[breadoven]

I've been using #6524 for a while now and it works fine. The only thing that might need double checking is the landing selection for normal RTH and WP RTH. I'm sure I checked this before but can't find any OSD recordings where RTH and WP RTH landing was set differently. All recordings are either both no landing or both set to land, So worth doing a quick test on this to check the landing setting works independently. If this is OK then it will be good to merge.

[stronnag]

I've been using #6524 for a while now and it works fine. The only thing that might need double checking is the landing selection for normal RTH and WP RTH. I'm sure I checked this before but can't find any OSD recordings where RTH and WP RTH landing was set differently. All recordings are either both no landing or both set to land, So worth doing a quick test on this to check the landing setting works independently. If this is OK then it will be good to merge.

I'll merge it later today; at least then we can simplify the safehome case; if there is a RTH/WP-RTH land problem that can be a separate PR.

[breadoven]

I've been using #6524 for a while now and it works fine. The only thing that might need double checking is the landing selection for normal RTH and WP RTH. I'm sure I checked this before but can't find any OSD recordings where RTH and WP RTH landing was set differently. All recordings are either both no landing or both set to land, So worth doing a quick test on this to check the landing setting works independently. If this is OK then it will be good to merge.

I'll merge it later today; at least then we can simplify the safehome case; if there is a RTH/WP-RTH land problem that can be a separate PR.

OK. Thanks for that. I'll probably test it tomorrow when the weather clears up.

[tonyyng]

Looking at breadoven's change in navigation.c, my change is no longer necessary. The logic flow should go through the regular RTH flow which should use safehomes.

I'm going to cancel this pull request.

@Jetrell Please test again when breadoven's changes have been merged.

[Jetrell]

@tonyyng
I ran some test with 6524, using safehome via RTH and FS. And also ran tests using safehome in waypoint missions.

Using Safehome alone. All safehome_usage_modes work, both via RX FS position and RX FS no pulses.

But as was mentioned, safehome will only work in a waypoint mission if safehome_usage_mode = RTH .
This limits the way safehome will operate under normal use.

@breadoven I know you like the idea of using RTH to bring your craft back lazy like. And want to use safehome if a FS occurs.
Safehome works this way if safehome_usage_mode = RTH_FS. But this usage mode will not work for a waypoint mission terminating at a safehome.

[breadoven]

I'm not entirely sure what you're saying @Jetrell. Just to clarify:

Safehomes only work when RTH is active. This could be caused by failsafe set to RTH, or RTH triggered by selection of RTH mode (failsafe could be real caused by Rx loss or simulated using failsafe mode). Safehomes can be set to only work on a failsafe RTH (safehome_usage_mode = RTH_FS) or both a failsafe RTH and a RTH activated by RTH mode (safehome_usage_mode = RTH).

In the case of missions, a mission can only be set to RTH at the end of the mission, it can't be set to terminate at a Safehome. With PR 6524 the RTH at the end of the mission behaves the same as a RTH triggered using RTH mode so its behaviour in relation to Safehomes should be the same, i.e. it should divert to a Safehome only if safehome_usage_mode = RTH is set. This is exactly what you would expect. It can't use a Safehome if safehome_usage_mode = RTH_FS is set because there is no failsafe present when a mission is running normally. I think this comes back to your different interpretation of the relationship between RTH and failsafe mode where you seem to see failsafe mode as a means of achieving RTH rather than using the mode that is specifically designed to instigate a RTH, RTH mode itself. But really RTH is merely an option can can be triggered during a failsafe, real or triggered by failsafe mode, it's not the reason failsafe mode exists (which is surely for testing failsafe without actually switching off the Tx ?).

If a failsafe does happen during a mission (real or simulated) then the mission ends and the failsafe procedure kicks in which should return to a Safehome same as failsafe at any other time. The exception to this is is if the mission failsafe override is active in which case the mission will ignore the failsafe and continue the mission. Having checked the code it appears there may be an issue in this case if the mission ends in a RTH and the failsafe continues to the end of the mission because in these specific circumstances failsafe remains in a dormant state where it does nothing other than monitor for the failsafe trigger to end (Rx recovered or failsafe mode switched off). It doesn't set the flag used by Safehomes (forcedRTHActivated) to detect a failsafe RTH so will only use a Safehome if set to safehome_usage_mode = RTH not if set to RTH_FS. Did you test a mission using the failsafe override (failsafe_mission = off) Jetrell ? I'm not sure this is much of issue because the mission failsafe override is probably only really used to allow a mission to knowingly fly out of range of the Tx rather than to allow it to continue in the case of a genuine failsafe. In this case you're expecting the failsafe to end once/if the craft makes it back from the mission and the signal is recovered.

[Jetrell]

@breadoven That was a lot to reply back too. Without going into to much detail. Failsafe mode selection was never used in my tests. It was only RTH mode selection.

Case 1 - When the last Waypoint was set to RTH, with a valid Safehome on arming.

• RX FS Position or RX FS No pulses
• Safehome_usage_mode = RTH
• RTH mode selection

It will fly to the safehome when RTH mode switch was triggered. And would do the same if the transmitter was turn off.
The waypoint mission will terminate at the safehome and land.
This is expected.

CASE 2 - When the last Waypoint was set to RTH, with a valid Safehome on arming.

• RX FS Position or RX FS No pulses
• Safehome_usage_mode = RTH_FS
• RTH mode selection

It will fly to the safehome if the transmitter is turned off. And will fly to the arming location if the RTH mode switch is triggered.
This is expected.
But the waypoint mission would terminate at the arming location and land. Not the safehome.

The purpose of safehome_usage_mode = RTH_FS is to only use safehome under a signal loss condition, Not manual RTH.
But it also prevents a waypoint mission safehome termination point.

The bottom line - People will not want to change from safehome_usage_mode = RTH_FS back to safehome_usage_mode = RTH just to run a waypoint mission that can use safehome on landing.

Remembering this is based around the new mission planner.

[breadoven]

I think the issue here is you seem to think a mission with RTH set should always return to a Safehome when there's no reason why it should. Why do you think it should out of interest ? It will return to the arming point the same as if you triggered manual RTH. The only time it would go to a Safehome is if safehome_usage_mode = RTH is set or failsafe is active. There was never any intention that a mission RTH would behave any differently to a normal RTH. So it seems to work as expected.

[tonyyng]

It will fly to the safehome if the transmitter is turned off. And will fly to the arming location if the RTH mode switch is triggered.
This is expected.
But the waypoint mission would terminate at the arming location and land. Not the safehome.

The purpose of safehome_usage_mode = RTH_FS is to only use safehome under a signal loss condition, Not manual RTH.
But it also prevents a waypoint mission safehome termination point.

The bottom line - People will not want to change from safehome_usage_mode = RTH_FS back to safehome_usage_mode = RTH just to run a waypoint mission that can use safehome on landing.

What you've described is exactly what I expect to happen. Why would someone expect a mission to end at a safehome when they've configured safehomes to only be used when failsafe occurs? If they want a mission to end at a safehome, specify its gps location as the last waypoint.

[breadoven]

It will fly to the safehome if the transmitter is turned off. And will fly to the arming location if the RTH mode switch is triggered.
This is expected.
But the waypoint mission would terminate at the arming location and land. Not the safehome.
The purpose of safehome_usage_mode = RTH_FS is to only use safehome under a signal loss condition, Not manual RTH.
But it also prevents a waypoint mission safehome termination point.
The bottom line - People will not want to change from safehome_usage_mode = RTH_FS back to safehome_usage_mode = RTH just to run a waypoint mission that can use safehome on landing.

What you've described is exactly what I expect to happen. Why would someone expect a mission to end at a safehome when they've configured safehomes to only be used when failsafe occurs? If they want a mission to end at a safehome, specify its gps location as the last waypoint.

Better still set the last WP as a Landing and it will land there. Just be careful if the landing elevation is higher than the arming elevation or it'll come down with a bump, even if it's a multirotor. See #6822. This is actually an issue for Safehomes if the the landing elevation is different to the arming elevation ... but best not to complicate things further perhaps.

[Jetrell]

@breadoven I totally understand your logic and why it works this way.

But the part that is important to note. Is that most users will not understand nor care about the logic. They just want something that is easy for them to use.

Arno has done a good job in designing the new Mission Planner. And it integrates the ability to easily setup a mission that can terminate at a safehome.
Most users hate the CLI and like the ease of using a simple mission planner GUI. But if they have to mess around trying to work out why one Safehome_usage_mode works and the other doesn't.... its no longer a simple GUI.

Does the non engineer in you get my meaning?

[tonyyng]

Arno has done a good job in designing the new Mission Planner. And it integrates the ability to easily setup a mission that can terminate at a safehome.

I haven't used the new Mission Planner. If it gives the impression that the mission terminates at a safehome, I think that is incorrect.

The default mode for safehome_usage_mode is RTH. If the user changes it to RTH_FS, they are choosing for safehomes to be used ONLY during a failsafe condition. This excludes a waypoint mission configured for RTH as the last action.

[breadoven]

But the Mission Control GUI needs to be set up to match what the firmware actually does so if what you say is correct Mission Control needs tweaking. I had a play with it last night and noticed that it allows you to set a RTH on an intermediary WP which isn't possible any more with the latest changes, RTH can only be set on the last WP. It did use to be possible but not now.

[stronnag]

But the Mission Control GUI needs to be set up to match what the firmware actually does so if what you say is correct Mission Control needs tweaking. I had a play with it last night and noticed that it allows you to set a RTH on an intermediary WP which isn't possible any more with the latest changes, RTH can only be set on the last WP. It did use to be possible but not now.

A mission planner may not even know what the flight target is.

• Make an offline plan with a graphical planner
• Upload to different FC / firmware version using a different tool.

[Jetrell]

I haven't used the new Mission Planner. If it gives the impression that the mission terminates at a safehome, I think that is incorrect.

It can be made terminate at a safehome. Its a feature it is capable of.
It can also plot, select and save a safehome on bing maps. Which make it much easier to implement.

But the Mission Control GUI needs to be set up to match what the firmware actually does so if what you say is correct Mission Control needs tweaking. I had a play with it last night and noticed that it allows you to set a RTH on an intermediary WP which isn't possible any more with the latest changes, RTH can only be set on the last WP. It did use to be possible but not now.

The RTH WP can be terminated at a selected safehome.
But its simplicity of setup will be lost of the firmware doesn't line up with the GUI. Users will want safehome and waypoint safehome both to work with the same usage mode,

[stronnag]

Planning safehome locations and mission planning are orthogonal in my view. It is not the firmware's job to match the user's interpretation of one (of several) planning tools -- in fact it's impossible; my interpretation is not another's interpretation.

[breadoven]

But the Mission Control GUI needs to be set up to match what the firmware actually does so if what you say is correct Mission Control needs tweaking. I had a play with it last night and noticed that it allows you to set a RTH on an intermediary WP which isn't possible any more with the latest changes, RTH can only be set on the last WP. It did use to be possible but not now.

A mission planner may not even know what the flight target is.

• Make an offline plan with a graphical planner
• Upload to different FC / firmware version using a different tool.

But aren't Safehomes and multiple RTH phases bespoke INAV mission features ?

[stronnag]

Sure, but If I create a mission with multiple RTHs, then I can always upload it to inav pre-1.0 - inav 2.5 and it should behave as specificed for those versions. The offline mission planner does not know apriori what the target might be. I quite contented fly 5 year mission plans on modern firmware.

[Jetrell]

Planning safehome locations and mission planning are orthogonal in my view. It is not the firmware's job to match the user's interpretation of one (of several) planning tools -- in fact it's impossible; my interpretation is not another's interpretation.

I understand.
But if the goal of this GUI is simplicity of mission planning and it has a safehome manager, to help with that.

I think it would assist users if safehome_usage_mode = RTH_FS could also terminate at a selected safehome when used in a waypoint mission. That way it doesn't effect the way regular safehome works.

[breadoven]

Sure, but If I create a mission with multiple RTHs, then I can always upload it to inav pre-1.0 - inav 2.5 and it should behave as specificed for those versions. The offline mission planner does not know apriori what the target might be. I quite contented fly 5 year mission plans on modern firmware.

Ah true, I'd forgotten about supporting old versions.

[tonyyng]

But if the goal of this GUI is simplicity of mission planning and it has a safehome manager, to help with that.

I think it would assist users if safehome_usage_mode = RTH_FS could also terminate at a selected safehome when used in a waypoint mission. That way it doesn't effect the way regular safehome works.

I disagree with your suggestion to change the safehome logic with regards to safehome_usage_mode = RTH_FS. I think the current behavior is correct.

It is great that Mission Planner is allowing you to configure safehomes, but if it is giving users the impression that safehomes can be used in a mission (other than to select its GPS location as a waypoint), I think a change needs to be made in Mission Planner.

[breadoven]

@Jetrell What makes you think WP5 above will go to the Safehome ? I can't see anything in Mission Control that sets this. It's just a WP set to RTH which means it will go back to where the arming point was, not the Safehome. It'll only go to the Safehome on failsafe or if the Safehome RTH setting allows.

[Jetrell]

@Jetrell What makes you think WP5 above will go to the Safehome ?

Because I have tested it with the earlier mentioned setting, And it does.

[Jetrell]

@breadoven The funny thing about that. Even if it isn't meant to work that way... It still can.
iNav is getting more and more edge case bugs. I've lost count over the years.

You can be sure if I found this. Many others will too. But I don't see this feature in the MP as a bad thing.

[tonyyng]

@Jetrell What makes you think WP5 above will go to the Safehome ?

Because I have tested it with the earlier mentioned setting, And it does.

I don't understand your response. However, I'll ask the question another way.

Earlier you said:

And it (aka Mission Planner) integrates the ability to easily setup a mission that can terminate at a safehome.

What aspect of Mission Planner implies that a mission is terminating at a safehome?

[Jetrell]

@tonyyng does my comment before this explain it?

Lack of clear documents will lead users to test things out. And what they find works. They will use.
What one person see's one way. Another will see differently.

Please don't take my comments as having a shot at you guys. You all do a great job. I'm just trying to speak up for people that don't have the knowledge of these systems that you do.

[breadoven]

@Jetrell What makes you think WP5 above will go to the Safehome ?

Because I have tested it with the earlier mentioned setting, And it does.

But it doesn't go to the Safehome when there's no failsafe and you select safehome_usage_mode = RTH_FS meaning there's no direct connection between the Safehome and the RTH on WP5. Any connection is dependent solely on the Safehome logic in INAV not what is shown graphically in Mission Control.

[Jetrell]

@breadoven I see what you mean.

To my way of looking at it. Why else did Arno include a Safehome manager in the mission planner. If it wasn't meant to work in conjunction with a WP mission?

I think he might be the guy to ask.

[stronnag]

Same reason as there's been a safe home planner in mwp for ages; to provide a GUI for configuring safe homes; utterly disconnected from missions.

• You can plan a mission without safehomes
• You can plan your safehomes without a mission

No connection.

[tonyyng]

@breadoven I see what you mean.

To my way of looking at it. Why else did Arno include a Safehome manager in the mission planner. If it wasn't meant to work in conjunction with a WP mission?

I think he might be the guy to ask.

If the basis of your reasoning for changing the safehome behavior, is that the Mission Planner allows you to define safehomes, then I disagree.

There is only one mapping feature in inav-configurator. It doesn't make sense to create another tab just to configure safehomes.

[Jetrell]

There is only one mapping feature in inav-configurator. It doesn't make sense to create another tab just to configure safehomes.

I respect that 👍
Thank you for your time and replies.