Various Landing Pattern fixes and add final approach speed #12238
+167
−27
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Addressed issues with scanning and interpreting landing sequences for fixed wing ArduPilot aircraft. Previously, landing sequences uploaded to ArduPilot fixed wing aircraft and then downloaded back weren't being reinterpreted as QGC LandingComplexItems. The system to detect a landing sequence and translate it back to a LandingComplexItem wasn't working correctly due to multiple assumptions about mission item parameters that weren't accurate for ArduPilot. The changes include adjusting parameter checks for NAV_LAND, NAV_LOITER_TO_ALT, NAV_WAYPOINT, and DO_LAND_START commands to align with ArduPilot's implementation, without modifying the existing logic for other firmwares.
When not using the "Use loiter to altitude" option in the Landing Pattern mission item, the heading of the glide slope still took into account the old loiter radius. Adjusted the QML code to change the loiter radius to 0 in landing patterns that use a waypoint as the approach start, which in turns lead to correct heading calculations. Ideally, the _recalcFromHeadingAndDistanceChange, _recalcFromRadiusChange and _recalcFromCoordinateChange should be refactored to account for the fact that a landing pattern can use a waypoint instead of a loiter. However, this fix works just as well and is much simpler.
Addressed an issue where the values of boolean Facts where the QVariant was of type int were not being correctly interpreted to drive the checked status of the QGCCheckBox. This was a problem with boolean Facts loaded from JSON where the default was "false", in which case the checkbox didn't work correctly.
Introduced an option for setting an airspeed for the final approach in the Landing Pattern editor, almost identical to the one found in standard waypoints, for the purposes of energy management before the glide slope. It works by inserting a DO_CHANGE_SPEED mission element right after the DO_LAND_START, in such a way that the speed is also changed in the event of an RTL. The option is unchecked by default.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Various Landing Pattern fixes and add final approach speed
Description
0e26836: Fix landing item scanning for ArduPilot fixed wing
Addressed issues with scanning and interpreting landing sequences for fixed wing ArduPilot aircraft. Previously, landing sequences uploaded to ArduPilot fixed wing aircraft and then downloaded back weren't being reinterpreted as QGC LandingComplexItems. The system to detect a landing sequence and translate it back to a LandingComplexItem wasn't working correctly due to multiple assumptions about mission item parameters that weren't accurate for ArduPilot.
The changes include adjusting parameter checks for NAV_LAND, NAV_LOITER_TO_ALT, NAV_WAYPOINT, and DO_LAND_START commands to align with ArduPilot's implementation, without modifying the existing logic for other firmwares.
22721c3: Fix waypoint glide slope heading calculations
When not using the "Use loiter to altitude" option in the Landing Pattern mission item, the heading of the glide slope still took into account the old loiter radius. Adjusted the QML code to change the loiter radius to 0 in landing patterns that use a waypoint as the approach start, which in turns lead to correct heading calculations.
Ideally, the _recalcFromHeadingAndDistanceChange, _recalcFromRadiusChange and _recalcFromCoordinateChange should be refactored to account for the fact that a landing pattern can use a waypoint instead of a loiter. However, this fix works just as well and is much simpler.
7482a0c: Fix boolean Fact interpretation in QGCCheckBox
Addressed an issue where the values of boolean Facts where the QVariant was of type int were not being correctly interpreted to drive the checked status of the QGCCheckBox. This was a problem with boolean Facts loaded from JSON where the default was "false", in which case the checkbox didn't work correctly.
cb4311e: Add final approach speed to the Landing Pattern
Introduced an option for setting an airspeed for the final approach in the Landing Pattern editor, almost identical to the one found in standard waypoints, for the purposes of energy management before the glide slope.
It works by inserting a DO_CHANGE_SPEED mission element right after the DO_LAND_START, in such a way that the speed is also changed in the event of an RTL. The option is unchecked by default.
Checklist:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.