-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
Add support for multiple landing sequences #12313
base: master
Are you sure you want to change the base?
Add support for multiple landing sequences #12313
Conversation
Updated the Fly View's flight plan drawing to match the Plan View, enabling support for discontinuities in missions (unconnected flight legs) in the former. Key changes: - Fly View now uses simpleFlightPathSegments, the same model used by Plan View, to draw flight paths. This enables proper handling of disconnected mission legs, which the previous _waypointPath approach did not support. - Flight plan arrows now appear in the same places between the Fly and the Plan Views. - Removed the old Fly View drawing logic and related members and properties.
Added an option to configure multiple landing sequences in a mission. This feature allows users to define alternative landing sites, which can be useful for contingency planning. When multiple landing sequences are present, the first one is used for the primary mission, but in the event of an RTL, the closest landing sequence will be used, as outlined in the MAVLink spec: https://mavlink.io/en/messages/common.html#MAV_CMD_DO_LAND_START. Key changes: - Disabled the restriction to only one landing sequence. - Modified LandingComplexItem to support scanning for multiple complex items, and configuring the DO_LAND_START mission items to contain the coordinates of the first element in the landing sequence. - Updated MissionController to handle multiple landing sequences, including proper flight path segment calculation and handling of discontinuities after landing commands. - The TerrainProfile displays the entire mission with any possible alternative landing sequences, but the mission stats (distance and time) represent the primary mission, up to the default landing. - Added an option in the Plan View settings to control this feature, defaulting to match the previous behavior.
Added an option in the Plan View settings to automatically set the coordinates of DO_LAND_START mission items to match the next waypoint in the mission. This is used to help find the closest landing sequence in the event of an RTL. This option is disabled by default to match the previous behavior.
So it's the lat/lon in the DO_LAND_START which is used to find the nearest landing pattern sequence for an RTL if there are multiple patterns. Is that correct? If that's the case, is there a reason why setting this with lat/lon/alt should not always be done?
I can see how maybe a commercial vehicle creator may want to create a custom version of QGC where this is not allowed. But for general use I wonder if you should be able to turn off this behavior. Any reason why this shouldn't be allowed by default? Maybe a popup, with a "Don't show again" type thing which tells the user what will happen if they add a second pattern. Then they can Yes/No it if they did it by accident? |
I wonder if an option is needed for this as well? I would change the handling of this to tweak DO_LAND_START in the scan code for the complex item on the way in. This way it only takes effect for landing patterns which were created using the Plan/Pattern support. It specifically does not touch DO_LAND_STARTs which may have been manually added to by the user in which case they control what they want themselves. |
At least in ArduPilot, its not necessary. The DO_LAND_START seems to get picked based on the coords of the next item, at least when no DO_LAND_START items specify any coords. However the MAVLink spec seems to suggest having it, so I assume other firmwares might need it, which is why I'm adding it as an option.
Fair point, I just figured I shouldn't change the existing behavior by default. No option in settings + a popup seems like a good idea but I think from a UX perspective it breaks the philosophy of mission planning in QGC which is meant to be fully intuitive. Maybe change the tool name to "Alternate Land"? Seems a bit too long. It can be kept as a fact so that custom builds can disable it if they want, like you say.
2647246 always generates the DO_LAND_START of a LandingComplexItem with the coords of the next item: ce1f246 only affects standalone DO_LAND_STARTS. It's meant as a helpful feature for when you often use manually defined landing sequences, to avoid having to copy the coords of the next item every time (and it also avoids relying on "Show all values" which is needed to do this, and is an advanced mode feature). I assume that the 2 most common use cases are default DO_LAND_STARTS, and having their coords match the next item with coords. If someone wants something else they can just disable this feature and get the current master behavior. |
Add support for multiple landing sequences
Description
Make isLandCommand true for LandingComplexItems.
Change plan drawing in Fly View to match Plan View:
Updated the Fly View's flight plan drawing to match the Plan View, enabling support for discontinuities in missions (unconnected flight legs) in the former.
Key changes:
Add support for multiple landing sequences:
Added an option to configure multiple landing sequences in a mission. This feature allows users to define alternative landing sites, which can be useful for contingency planning. When multiple landing sequences are present, the first one is used for the primary mission, but in the event of an RTL, the closest landing sequence will be used, as outlined in the MAVLink spec: https://mavlink.io/en/messages/common.html#MAV_CMD_DO_LAND_START.
Key changes:
Add support to set Land Start coords to next item:
Added an option in the Plan View settings to automatically set the coordinates of DO_LAND_START mission items to match the next waypoint in the mission. This is used to help find the closest landing sequence in the event of an RTL. This option is disabled by default to match the previous behavior.
Checklist:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.