Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix mission with LAND_START and RTL item #13734

Merged
merged 4 commits into from
Dec 23, 2019
Merged

Conversation

julianoes
Copy link
Contributor

This prevents a corner case when a VTOL user has set a LAND_START item as well as checked the box to end the mission with RTL.

What happens on RTL is that navigator would switch to mission mode on RTL and start with land_start, and then continue to the RTL item. At this point, navigator would send the vehicle_command for RTL to commander which would deny it because it is already in RTL mode. Thus navigator won't (re)set any items to actually do RTL and it means the vehicle will just head to whatever setpoint it received last.

This PR fixes this corner case by:

  1. Enabling the fixedwing mission feasibility checks for VTOLs but without requiring a landing sequence.
  2. Checking for LAND_START and a RTL item in a mission using the fixedwing mission feasibility checker.

Tested in SITL.

Discovered by @sfuhrer.

@julianoes julianoes requested review from dagar and sfuhrer December 12, 2019 13:19
A VTOL mission can also contain a fixedwing landing. Therefore, I think,
it makes sense to run the fixedwing checks as well, however, don't check
for a landing start necessarily.
This is a check to protect a user from upload a mission which includes a
land_start marker as well as a RTL mission item.

This works around the problem that we experienced where the navigator
would switch to mission mode on RTL and start with land_start, and then
continue to the RTL item. At this point, navigator would send the
vehicle_command for RTL to commander which would deny it because it is
already in RTL mode. Thus navigator won't (re)set any items to actually
do RTL and it means the vehicle will just head to whatever setpoint it
received last.
@julianoes julianoes force-pushed the pr-fix-land-with-rtl branch from e90cea5 to 6b00764 Compare December 16, 2019 12:30
@sfuhrer
Copy link
Contributor

sfuhrer commented Dec 16, 2019

Thanks for looking into this @julianoes . I agree that a mission feasibility check makes sense here, as there is really no point in planning a mission with a land start marker and then a RTL waypoint.

While testing it I though run into issues with the Fixed wing feasibility checker, as it now checks the mission for an appropriate FW landing approach (which ofc doesn't need to be there for a VTOL). We thus should exclude this check for VTOL.
image

@julianoes
Copy link
Contributor Author

@sfuhrer but I thought I disabled that it requires a landing point here:
https://github.com/PX4/Firmware/pull/13734/files#diff-3f698c24ebab3cb3866d13e69f8e5459R87

What mission are you uploading to cause this?

…te function

Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
@sfuhrer
Copy link
Contributor

sfuhrer commented Dec 17, 2019

@sfuhrer but I thought I disabled that it requires a landing point here:
https://github.com/PX4/Firmware/pull/13734/files#diff-3f698c24ebab3cb3866d13e69f8e5459R87

What mission are you uploading to cause this?

You just disabled the check for "having a land start marker", but if missions contain one then all the FW landing checks still run.

I've added another commit with the VTOL landing checks in a separate function.
Pros: only running the checks really required for VTOL, plus enabling us to add additional VTOL specific checks in the future (eg requiring a loiter to altitude before back transition (see eg #12413)
Cons: adds some duplicated code

What do you think @julianoes ?

@julianoes
Copy link
Contributor Author

Makes sense, thanks @sfuhrer!

Copy link
Contributor Author

@julianoes julianoes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this looks correct.

@dagar
Copy link
Member

dagar commented Dec 23, 2019

Was this closed intentionally?

@dagar dagar reopened this Dec 23, 2019
@LorenzMeier
Copy link
Member

No, that was a weird Github interaction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants