Repository navigation
[#337] Allow continuous aliveness checkers - #354
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: cbb3bf7288
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
Pull request overview
Adds support for “continuous” aliveness checkers so selected @aliveness_checker methods can be evaluated via Basilisk events during integration and immediately interrupt an environment step upon failure, while preserving existing step-level checker behavior.
Changes:
- Extend
@aliveness_checkerto acceptcontinuousandcheck_rateoptions and expose them on the wrapped checker. - Create satellite-level Basilisk events for continuous checkers during simulator initialization.
- Add unit + integration tests validating decorator metadata and step-level vs continuous interruption behavior.
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| tests/unittest/utils/test_functional.py | Adds unit tests for new decorator defaults and kwargs (continuous, check_rate). |
| tests/unittest/sats/test_satellite.py | Adds unit test verifying continuous checkers create terminal Basilisk events and mark the satellite dead. |
| tests/integration/sim/test_int_dynamics.py | Adds integration test comparing step-level vs continuous termination time. |
| src/bsk_rl/utils/functional.py | Updates aliveness_checker decorator to support optional configuration and store metadata on wrapped callables. |
| src/bsk_rl/sim/simulator.py | Hooks satellite continuous aliveness event setup into simulator initialization. |
| src/bsk_rl/sim/fsw/init.py | Documents the new continuous=True behavior for FSW checkers. |
| src/bsk_rl/sim/dyn/init.py | Documents the new continuous=True behavior for dynamics checkers. |
| src/bsk_rl/sats/satellite.py | Implements setup_aliveness_events() to create terminal Basilisk events for continuous checkers. |
| docs/source/release_notes.rst | Adds release note entry for continuous aliveness checkers. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Yume27
left a comment
There was a problem hiding this comment.
Thank you for adding this functionality. This helps make the simulation behavior more realistic for operations where failures can occur during a long environment step. That said, I think some existing aliveness checkers would benefit from using this behavior by default. In particular, battery_valid and rw_speeds_valid seem like strong candidates for continuous=True, since transient battery depletion or reaction wheel overspeed should not be missed if they occur mid-step. Could we update those checkers to use continuous aliveness checking by default?
|
Thanks for the review @Yume27 I’ve been busy these past few days and haven’t had time to work through the comments yet. I’ll get back to this and update the PR in the next couple of days. |
56db173 to
605d62a
Compare
Description
Closes #337
Closes #59
Adds
continuous=Trueto@aliveness_checkerso failures can interrupt an environment step through Basilisk events.check_ratesets the minimum interval between checks in seconds and defaults to the simulator rate.Battery charge and reaction wheel speed checks now use continuous checking by default. This catches failures that would otherwise be missed if the state recovers before the environment step ends. Other checkers retain their existing step-level behavior.
Continuous and step-level failures share the same logging function. A continuous failure records the time of death and emits one warning without evaluating the checker again.
Type of change
How should this pull request be reviewed?
How Has This Been Tested?
Checklist