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.
Needed to unblock #10355, but this is also a good excuse to fix these bogus dependencies.
Navigator is currently dependant on the VTOL parameters VT_B_DEC_MSS and VT_B_REV_DEL. Let's either handle this with the VTOL controller publishing a status message, or falling back to the old param API.
I'd vote for an orb based solution if @RomanBapst could assist. I'll be mostly unavailable until next week.
Similar to the way the FW position controller publishes
position_controller_status
for the L1 distance that's used by navigator as the acceptance radius, we could have the vtol controller publish an appropriate acceptance distance for back transition (how VT_B_DEC_MSS and VT_B_REV_DEL are used). https://github.com/PX4/Firmware/blob/master/src/modules/navigator/mission_block.cpp#L291-L305Going forward I think we should strictly enforce parameter module boundaries with only a few global exceptions (SYS and CAL?).