Introduce global position relaxed #24280
Open
+71
−12
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
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: 464 byte (0.02 %)]px4_fmu-v6x [Total VM Diff: 480 byte (0.02 %)]Updated: 2025-02-13T07:58:00 |
|
I'm definitely in favor of handling these differences contextually, it's long overdue. The parameter naming isn't great ( My initial reaction after a first pass is that if we're |
- allow fixed wing vehicles to indefinitely navigate if they are at least wind dead-reckoning Signed-off-by: RomanBapst <[email protected]>
RomanBapst
force-pushed
the
pr-global_pos_relaxed
branch
from
d664ee5 to
e55c4ab
Compare
|
@dagar I removed the parameter now and set the accuracy threshold for global position relaxed to infinity. This enables fixed wing vehicles to navigate indefinitely if they are at least wind dead-reckoning (otherwise global position is not valid). |
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.
Solved Problem
Fixed wing vehicles with an airspeed sensor are able to constrain position drift in GNSS denied environments. This use case usually requires the flight controller to accept low position accuracy reported by the estimator (high eph).
The parameter
COM_POS_FS_EPHdefines a threshold for the accuracy above which a failsafe is triggered (e.g. descend mode). In the above described use case, this parameter is usually set to Infinity, in order to allow unlimited operation. Usually the operator handles the position drift by manually resetting the vehicle position to a known location, based on visual cues from the camera.This however has undesired side effects for VTOL vehicles equipped with a flow sensor when they are coming back for landing.
As soon as the flow sensor gets into range (mostly during the descend phase after the backtransition), global position is considered valid again (because there is no uncertainty limit) and a mode like RTL, which requires global position, is resumed (assuming the vehicle came back in RTL mode). In practice however, this leads to the vehicle flying to an inaccurate land location and gives the user the impression that it's "flying away". It would be much more desirable for the vehicle to just land at the location after the backtransition, relying on the user to correct the error using the nudging feature.
It all boils down to the idea of having separate accuracy requirements for navigation modes for multicopter and fixed wing.
Solution
Add the concept of a relaxed global position validity. This refers to global position being valid when the associated uncertainty is below a threshold defined by the parameter
COM_POS_R_FS_EPH.Changelog Entry
For release notes:
Alternatives
We could also ...
Test coverage
Context
Related links, screenshot before/after, video