Introduce global position relaxed #24280
Open
+200
−13
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: 448 byte (0.02 %)]px4_fmu-v6x [Total VM Diff: 432 byte (0.02 %)]Updated: 2025-02-21T17:10:01 |
|
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 |
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). |
RomanBapst
force-pushed
the
pr-global_pos_relaxed
branch
from
e55c4ab to
eea9764
Compare
sfuhrer
force-pushed
the
pr-global_pos_relaxed
branch
from
328d871 to
3b0c38d
Compare
|
I've rebased on main and hopefully fix the CI ROS translation failure with 3b0c38d |
sfuhrer
force-pushed
the
pr-global_pos_relaxed
branch
from
3b0c38d to
9e51571
Compare
|
Docs update here? BTW, are we at the point where we should add a page on "Configuration/Flying for GPS denied environments?" |
sfuhrer
force-pushed
the
pr-global_pos_relaxed
branch
2 times, most recently
from
01216f1 to
0d6409d
Compare
RomanBapst
force-pushed
the
pr-global_pos_relaxed
branch
from
0d6409d to
d2f1025
Compare
|
@hamishwillee Would this section be the right place to add the docs? Currently the docs says the following:
Maybe it's time to add a dedicated section which shows the requirements for each mode and what the differences between the vehicle types are? The mode requirements are actually defined here, so we could potentially even auto-generate a table. |
That would be a great starting point. Other places include
So at an entry point level, we're partially down this path with things like the boxes at the top of (some) modes, such as FW Land mode. This is where the information is most useful - as a reader of FW docs I don't actually care much what MC Land might have as its requirements.
Ideally we could generate that automatically! If we can't do it per-page, a link to a page for "up to date information" or similar might help. Note the requirements are mentioned in https://docs.px4.io/main/en/concept/flight_modes.html#mode-restrictions but it is not user friendly or focused to this particular need. I'll have a bit more of a think, because we definitely need to do this a bit better. But in the meantime, updates would be appreciated. |
- allow fixed wing vehicles to indefinitely navigate if they are at least wind dead-reckoning Signed-off-by: RomanBapst <bapstroman@gmail.com>
Signed-off-by: RomanBapst <bapstroman@gmail.com>
Signed-off-by: Silvan <silvan@auterion.com>
Signed-off-by: Silvan <silvan@auterion.com>
Signed-off-by: Silvan <silvan@auterion.com>
RomanBapst
force-pushed
the
pr-global_pos_relaxed
branch
from
d2f1025 to
0765f7d
Compare
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