fix(failsafe): allow orbit on the first command after a failsafe#27673
Open
elisaaferraraa wants to merge 1 commit into
Open
fix(failsafe): allow orbit on the first command after a failsafe#27673elisaaferraraa wants to merge 1 commit into
elisaaferraraa wants to merge 1 commit into
Conversation
modifyUserIntendedMode() downgrades a requested Orbit to Loiter when releasing control after an active failsafe action, to avoid silently auto-resuming a stale Orbit intention. It could not distinguish that auto-resume from a fresh, explicit DO_ORBIT the operator sends right after resolving the failsafe: two DO_ORBIT commands where needed to actually re-start an orbit. Now using user_intended_mode_updated signal, the downgrade is skipped when the orbit is explicitely requested.
| ASSERT_FALSE(failsafe.userTakeoverActive()); | ||
| } | ||
|
|
||
| TEST_F(FailsafeTest, orbit_after_failsafe_explicit_command_allowed) |
Contributor
There was a problem hiding this comment.
[error] google-readability-avoid-underscore-in-googletest-name [error]
avoid using "_" in test name "orbit_after_failsafe_explicit_command_allowed" according to Googletest FAQ
| ASSERT_EQ(updated_user_intented_mode, vehicle_status_s::NAVIGATION_STATE_ORBIT); | ||
| } | ||
|
|
||
| TEST_F(FailsafeTest, orbit_autoresume_after_failsafe_downgraded_to_loiter) |
Contributor
There was a problem hiding this comment.
[error] google-readability-avoid-underscore-in-googletest-name [error]
avoid using "_" in test name "orbit_autoresume_after_failsafe_downgraded_to_loiter" according to Googletest FAQ
Contributor
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: 8 byte (0 %)]px4_fmu-v6x [Total VM Diff: 0 byte (0 %)]Updated: 2026-06-15T14:34:26 |
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.
Problem
After a failsafe occurs and is resolved, the first
VEHICLE_CMD_DO_ORBIT(34) isaccepted but the vehicle switches to Hold/Loiter instead of Orbit; only a
second orbit command actually starts the orbit. (Image below).
The reason is that
Failsafe::modifyUserIntendedMode()rewrites a requestedORBITtoAUTO_LOITERwhen releasing control after an active failsafe.That guard exists to stops a stale Orbit intention from auto-resuming, since the orbit task resets
its center to the current position and radius/velocity to defaults on
activation. But the check couldn't tell that auto-resume apart from an explicit
DO_ORBITthe operator just sent: on the first command the previous cycle's action is still the failsafe action, so the command isdowngraded; on the second command the previous action is
None, so it goesthrough.
Solution
FailsafeBase::update()already computes a combineduser_intended_mode_updatedsignal. We make
modifyUserIntendedMode()use it and apply theORBIT -> LOITERdowngrade only when the orbit was not explicitly requested.An explicit operator
DO_ORBITafter a resolved failsafe nowenters Orbit on the first command, while a stale auto-resume is still
downgraded to Loiter.
Testing
functional-failsafe_test, all pass) : two new cases: a freshDO_ORBITafter a cleared failsafe entersORBIT; a staleORBITintention auto-resuming after a transient failsafe is still downgraded to
AUTO_LOITER.gz_x500): took off, triggered a geofence Hold failsafe,cleared it, and sent a single
DO_ORBIT. Log confirmsnav_stategoesdirectly Hold(4) → ORBIT(21) on the first command, with
vehicle_status.failsafeactive in the cycle immediately prior. (Image below)