Mode configuration to make a mode not user selectable #131
Conversation
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
bkueng
approved these changes
Jul 15, 2025
bkueng
force-pushed
the
mission_execution
branch
2 times, most recently
from
9878780 to
91bc5f5
Compare
- allow to disable the health check watchdog timer (useful when debugging unit tests) - allow to override sendCommandSync (so it can be mocked in unit tests) - allow to skip message compatibility check in mode executor - fake registration: set mode name
bkueng
force-pushed
the
mission_execution
branch
from
656cd92 to
11aeacb
Compare
…ivate actions This is to make sure that actions using timers or other events cannot use it anymore. This is mostly a safeguard as actions get deactivated and can prevent it on their own.
Allows actions to detect when being resumed to restore the correct state.
This is to ensure that if an action calls on_completed() after an abort happended or the mission was deactivated (e.g. from a timer), the mission is not continued.
It is EOL and the build is failing
using doxygen -u
bkueng
force-pushed
the
mission_execution
branch
from
11aeacb to
968d47b
Compare
based on newer version (LLVM 19)
bkueng
force-pushed
the
mode-not-user-selectable
branch
from
9d222ba to
ac6367d
Compare
eyeam3
changed the title
… false Might happen in case a new message got added, and PX4 is older.
when using multiple modes and/or executors, as the check takes a bit of time.
It can become invalid when DDS messages do not get through to PX4 or are too much delayed, thus flagged as unresponsive by PX4, while other modes are still registered.
See code comment for explanation
This is in order to have deterministic behavior. In particular, if there are multiple modes (with executor), the (de)activation callback order was not determined with multiple status subscriptions. This can be surprising and leading to different outcomes depending on the order. For example this happens in case there is a mission executor with a custom mode, and the custom mode is running. When the user switches into another mode, the deactivation of the mode and the mission are called at the same time (with the same topic update). This happens now in the order of how the mission executor and mode are instantiated on startup.
bkueng
force-pushed
the
mode-not-user-selectable
branch
from
ac6367d to
03250b5
Compare
bkueng
force-pushed
the
mission_execution
branch
from
8cb4268 to
1578226
Compare
bkueng
force-pushed
the
mission_execution
branch
4 times, most recently
from
bd33c24 to
afd89b0
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.
Some modes should only be run within the context of a mode executor and the user should not be able to select them in the GCS.
With this change, the external component registration request can be used to set if a mode is selectable or not.