-
Notifications
You must be signed in to change notification settings - Fork 18k
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
Plane: Add climb slope minimum height parameter #29077
base: master
Are you sure you want to change the base?
Plane: Add climb slope minimum height parameter #29077
Conversation
needs proper library commit splits |
Probably needs parameter conversion for the changed params no? https://ardupilot.org/dev/docs/code-overview-adding-a-new-parameter.html#parameter-conversion-expiration |
This seems to make sense, what do you think @Ryanf55? |
Many thanks for the contribution! I like the naming change on first glance, perhaps that's worth splitting to it's own PR? The other change also makes sense. If we could get some exact steps to reproduce the poor behavior in SITL, so I can see a before/after from this PR, that would be fantastic. Some recommendation on which plots you are looking at would be helpful. At least for me, who's less experienced, understanding what the steps you take to reproduce the behavior and what graphs/logs you check are very useful. |
Before and after logs are included in the PR message: the difference can be seen in any altitude plot, where with master we get an undesired steep climb up to the final altitude of the problematic leg, and with this PR we only get a small steep climb up to the "safe height" (CLMB_SLOPE_HGT) and then we resume the expected slope. You can replicate them by running the flight plan in SITL with default params. It's worth noting that this wouldn't always happen in master as it depends on the height of the aircraft upon entering the leg, as can be seen in the log provided where a leg that's identical in terms of altitude difference is performed correctly. |
Maybe I'm missing something, but I don't think so? Given that it's just a name change and the place in the eeprom hasn't changed. So far I've been able to change between master and this PR with the values carrying over no problem. |
1c767af
to
ccf01bd
Compare
As mentioned by Henry, separate PRs for a name change and functionality addition would be a very good idea. |
@peterbarker Can you confirm if param conversion is needed for the name changes? |
ccf01bd
to
ae51af9
Compare
Moved the slope name changes to #29087 |
|
||
// @Param: CLMB_SLOPE_HGT | ||
// @DisplayName: Climb slope mininum height | ||
// @Description: Sets the minimum height above home at which the aircraft will apply a climb slope between waypoints. Below it, the aircraft will ascend immediately, and will only resume the requested trajectory upon reaching this height. This prevents unsafe behavior such as attempting to slowly gain altitude near obstacles. The default value of 20m ensures safe operations in most environments, but it can be adjusted based on specific terrain or operational needs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like using set_altitude_offset_location() in setup_glide_slope() means this will now work correctly if terrain following. Do I have that right?
IMO that would be a very good thing, so should this comment be changed to reflect that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not entirely sure if I understand, but I think it should work about the same as before for terrain following. The only differences are that now all legs are treated as altitude slopes regardless of the height at which the aircraft reaches them, and that the logic to follow altitude slopes now makes the aircraft climb as fast as possible when below CLMB_SLOPE_HGT, as a safety feature. It then resumes the correct trajectory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd love to see this in master. LGTM.
Slope treatment for a flight leg was conditioned to a minimum height of 20m (which was a hardcoded value and only documented in a comment in the code), below which an immediate altitude change was performed for that leg. This caused unpredictable results for flight plans with waypoints at exactly 20m followed by a climb, as the aircraft could, depending on chance, be above or below the height demand, resulting in very different trajectories. This commit addresses that issue with the following changes: - Added a parameter to control the minimum height at which a gradual climb slope can be performed. This documents the original feature and retains the safety aspect of it. - Changed the behavior when below said minimum height to only immediately climb up to the safe height, regaining the intended climb slope afterwards. This leverages existing code for recalculating climb slopes, provides a good balance between safety and following the flight plan as intended, and fixes the core issue of different trajectories being taken based on random external factors.
ae51af9
to
a5d4bb8
Compare
Plane: Add climb slope minimum height parameter
Description
Plane: Add climb slope minimum height parameter:
Slope treatment for a flight leg was conditioned to a minimum height of 20m (which was a hardcoded value and only documented in a comment in the code), below which an immediate altitude change was performed for that leg. This caused unpredictable results for flight plans with waypoints at exactly 20m followed by a climb, as the aircraft could, depending on chance, be above or below the height demand, resulting in very different trajectories.
This commit addresses that issue with the following changes:
Testing flight plan and logs
testing-logs.zip