fix(flight_mode_manager): fix terrain following position setpoint#26975
Merged
fix(flight_mode_manager): fix terrain following position setpoint#26975
Conversation
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: 96 byte (0 %)]px4_fmu-v6x [Total VM Diff: 96 byte (0 %)]Updated: 2026-04-04T22:18:17 |
In MPC_ALT_MODE=1 terrain following, the smoothing block was overwriting the parent class's terrain-adjusted position setpoint. Unify terrain hold and terrain following into a single terrain_position flag that syncs the smoothing block to the parent's position, preventing divergence and simplifying transition handling.
fcfa4aa to
c0be2b5
Compare
Contributor
Author
|
I tested this in simulation and it works as expected |
…lass FlightTaskManualAltitudeSmoothVel re-derived the parent's terrain gate in _setOutputState() to decide whether to keep the parent's position setpoint or overwrite it with the smoothing block. Two problems with that: 1. The condition was duplicated verbatim from the parent's gate in _updateAltitudeLock(), so any future change there would silently break the child. 2. The parent also invokes _terrainFollowing() from the min-altitude safety branch (MPC_ALT_MODE != 1 && !_terrain_hold but below hagl_min while braking). The child's open-coded condition did not cover that case, so the smoothing block still overwrote a valid terrain-adjusted setpoint there. Move ownership of the decision into the parent: _terrainFollowing() sets _z_setpoint_from_terrain iff it produced a finite setpoint, and _updateAltitudeLock() resets the flag at the top of each iteration. The child now reads the flag instead of re-deriving the condition, which also fixes the min-altitude safety branch above. _z_setpoint_from_terrain is named to stay semantically distinct from _terrain_hold (an MPC_ALT_MODE=2 sub-state that gates the terrain following logic).
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: 72 byte (0 %)]px4_fmu-v6x [Total VM Diff: 64 byte (0 %)]Updated: 2026-04-14T20:49:04 |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes terrain-following altitude behavior in MPC_ALT_MODE=1 when using acceleration-based position mode (FlightTaskManualAltitudeSmoothVel) by preventing the smoothing output stage from overwriting the terrain-adjusted Z position setpoint computed by the parent task.
Changes:
- Introduce a base-class flag (
_z_setpoint_from_terrain) inFlightTaskManualAltitudeto indicate when_terrainFollowing()produced the Z position setpoint for the current iteration. - Update
FlightTaskManualAltitudeSmoothVelto preserve terrain-driven_position_setpoint(2)and keep the smoothing state synchronized across terrain/non-terrain transitions.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/modules/flight_mode_manager/tasks/ManualAltitudeSmoothVel/FlightTaskManualAltitudeSmoothVel.hpp | Replace previous terrain-hold tracking with a flag that mirrors parent terrain-driven Z state across iterations. |
| src/modules/flight_mode_manager/tasks/ManualAltitudeSmoothVel/FlightTaskManualAltitudeSmoothVel.cpp | Avoid overwriting terrain-driven Z position setpoint; synchronize smoothing state and handle transition off terrain-driven Z. |
| src/modules/flight_mode_manager/tasks/ManualAltitude/FlightTaskManualAltitude.hpp | Add _z_setpoint_from_terrain to expose “terrain drove Z this iteration” to derived tasks. |
| src/modules/flight_mode_manager/tasks/ManualAltitude/FlightTaskManualAltitude.cpp | Reset/set _z_setpoint_from_terrain per-iteration and mark it after _terrainFollowing() based on whether it produced a finite Z setpoint. |
julianoes
approved these changes
May 4, 2026
Contributor
julianoes
left a comment
There was a problem hiding this comment.
This is better than my fix.
Contributor
|
Tested on my end, fixes the problem I saw. |
This file contains hidden or 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
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.
Summary
MPC_ALT_MODE=1(terrain following), the smoothing block in_setOutputState()was unconditionally overwriting the terrain-adjusted position setpoint computed by the parent class, effectively making terrain following non-functional when using acceleration-based position mode (FlightTaskManualAltitudeSmoothVel)FlightTaskManualAltitudevia a_z_setpoint_from_terrainflag. Children that manage their own smoothing read the flag instead of re-deriving the terrain gate_terrainFollowing()from the min-altitude safety branch (when braking below the distance sensor's minimum valid range —vehicle_local_position.hagl_min, populated by EKF2 — regardless ofMPC_ALT_MODE). That setpoint is now also preserved through the smoothing block