ENH: acceleration data to trigger parachutes#911
ENH: acceleration data to trigger parachutes#911ViniciusCMB wants to merge 19 commits intoRocketPy-Team:developfrom
Conversation
…Team#XXX) * ENH: add u_dot parameter computation inside parachute trigger evaluation. * ENH: add acceleration_noise_function parameter to Flight class for realistic IMU simulation. * ENH: implement automatic detection of trigger signature to compute derivatives only when needed. * TST: add unit tests for parachute trigger with acceleration data and noise injection. * TST: add test runner for trigger acceleration validation without full test suite dependencies.
…tion This enhancement enables realistic avionics algorithms by providing access to acceleration data (u_dot) within parachute trigger functions, simulating how real flight computers use accelerometers (IMU) to detect flight phases. * ENH: Pass acceleration data (u_dot) to parachute trigger callbacks - Flight class now computes and injects u_dot derivatives into triggers - Automatic detection of trigger signatures to optimize performance - Only calculates u_dot when trigger explicitly requires it * ENH: Add built-in acceleration-based trigger functions - detect_apogee_acceleration: Detects apogee via vz ≈ 0 and az < 0 - detect_motor_burnout: Detects motor shutdown by acceleration drop - detect_freefall: Detects free-fall condition (low total acceleration) - detect_liftoff: Detects liftoff by high total acceleration - altitude_trigger_factory: Factory for altitude-based triggers * ENH: Implement optional accelerometer noise injection - New parameter acceleration_noise_function in Flight.__init__ - Simulates MEMS accelerometer noise (typical 0.1-0.3 m/s²) - Applied transparently to all acceleration-based triggers * TST: Add comprehensive unit tests for trigger evaluation - Validates u_dot computation and noise injection - Tests backward compatibility with legacy 3-parameter triggers - Ensures performance optimization skips u_dot for non-accelerating triggers Notes ----- - Triggers can now use signatures: (p, h, y) or (p, h, y, u_dot/acc/acceleration) - Built-in string triggers: apogee, apogee_acc, burnout, freefall, liftoff - Performance: u_dot computation doubles physics evaluations at trigger points - Fully backward compatible with existing altitude and custom triggers
Allow parachute triggers to accept (p, h, y, sensors, u_dot); Flight passes sensors+u_dot, computing u_dot on demand with noise; numeric/apogee legacy triggers carry metadata.\n\nTests: pytest tests/unit/test_parachute_trigger_acceleration.py -v\nLint: black rocketpy tests && ruff check rocketpy tests
|
Fixed the linting/test errors reported by the CI workflow in the latest commit. |
|
@ViniciusCMB how do you compare your implementation against #854, is there any overlap we should be worried about? |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #911 +/- ##
===========================================
+ Coverage 80.27% 81.09% +0.82%
===========================================
Files 104 107 +3
Lines 12769 13918 +1149
===========================================
+ Hits 10250 11287 +1037
- Misses 2519 2631 +112 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
I have reviewed the definition of Controllers and analyzed the __simulate loop in flight.py. My Conclusion: While Controllers allow for dynamic logic, the RocketPy simulation engine iterates over them in separate loops:
Impact Assessment:
However, since both modify the critical __simulate method and #854 involves significant changes to the Controller architecture (10 files), I cannot guarantee zero friction without running an integration test merging both branches. I am available to rebase and test my branch on top of #854 once it is merged to ensure stability. |
|
@ViniciusCMB I have merged the #854 so you can rebase your work on top of develop branch again. Pls fix conflicts and linters so we can proceed with the review. |
…iggers - TestTriggerSignatures: Validates 3, 4, and 5-parameter trigger signatures - TestBuiltInTriggers: Tests all built-in triggers (apogee_acc, burnout, freefall, liftoff) - TestParachuteInitialization: Verifies parachute creation with different trigger types - TestEdgeCases: Covers NaN/Inf handling, low altitude, and error conditions Tests use AAA pattern (Arrange, Act, Assert) and follow NumPy docstring style. All edge cases for realistic avionics simulation are covered. Fixes codecov patch coverage from 42.85% to >85%.
… triggers - Created docs/user/parachute_triggers.rst with complete guide - Enhanced Parachute class docstring with trigger signature details - Added parachute_triggers.rst to docs/user/index.rst Documentation covers: - Built-in triggers (burnout, apogee_acc, freefall, liftoff) - Custom trigger examples (3, 4, and 5-parameter signatures) - IMU noise simulation - Performance considerations - Best practices and complete dual-deploy example
- Reorder imports: standard library before third-party - Prefix unused arguments with underscore - Add broad-exception-caught disable for test runner
Direct calls to parachute.triggerfunc() were missing the u_dot parameter, causing TypeError in unit tests. Added u_dot=None to non-overshoot and overshoot trigger evaluation paths where u_dot is not computed. Fixes test failures in: - tests/unit/simulation/test_flight.py - tests/unit/test_utilities.py - tests/unit/test_rail_buttons_bending_moments.py - tests/unit/test_flight_data_exporter.py
There was a problem hiding this comment.
do you really need try/except blocks here?
There was a problem hiding this comment.
Pull request overview
This pull request adds acceleration-based parachute triggers with IMU sensor simulation to RocketPy, enabling realistic avionics algorithms that mimic real-world flight computers. The implementation allows users to trigger parachute deployment based on accelerometer data (motor burnout, apogee, freefall, liftoff) while maintaining full backward compatibility with existing altitude and velocity-based triggers.
Key Changes:
- Four built-in acceleration-based trigger functions with edge case handling (NaN/Inf protection)
- Flexible trigger function signatures supporting 3, 4, or 5 parameters for legacy and new use cases
- Optional IMU noise simulation via
acceleration_noise_functionparameter in Flight class - Performance optimization through lazy evaluation (u_dot computed only when needed)
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 21 comments.
Show a summary per file
| File | Description |
|---|---|
tests/unit/test_parachute_triggers.py |
New test file with basic trigger tests, but uses non-standard test naming and custom runner |
tests/unit/test_parachute_trigger_acceleration.py |
Comprehensive test suite for acceleration triggers with proper pytest structure and AAA pattern |
rocketpy/simulation/flight.py |
Adds _evaluate_parachute_trigger helper method and acceleration_noise_function parameter; includes new import for inspect module |
rocketpy/rocket/parachute.py |
Implements four built-in trigger functions and flexible wrapper for multi-signature support |
docs/user/parachute_triggers.rst |
Comprehensive documentation with examples, best practices, and performance considerations |
docs/user/index.rst |
Adds parachute triggers documentation to table of contents |
|
@MateusStano I willtake a look at your comments and try to get back to you in case @ViniciusCMB doesn't do. However, Vinicius, if you are still available to contribute, please take a look at the comments,try to solve all of them and push it back here. |
Almost done! |
ViniciusCMB
changed the title
|
@Gui-FernandesBR, @MateusStano, I was really focused on the original issue and ended up implementing the "liftoff", "burnout", and other triggers as built-ins, even though it doesn't make much sense for the parachute (I believe it might be useful for other deployables, though). As for the noise sensor, I just read about it in the issue and implemented it; I wasn't aware it had already been done. I removed the excessive checks because, at the time, I hadn't fully read the documentation and was worried about avoidable errors showing up. |
|
@ViniciusCMB you have mark every comment as "resolved" before we start to review again. This makes the review process much easier. |
Pull Request: Add Acceleration-Based Parachute Triggers with IMU Sensor Simulation
Pull request type
Checklist
black) has been run locallyWhy this matters
This is a critical feature for advanced users simulating realistic avionics.
Real flight computers rely heavily on accelerometer signals (IMU) for event
detection (liftoff, burnout, coast/free-fall behavior), while pressure/GPS-only
logic is often noisier or slower in practice.
Until now, parachute triggers primarily relied on pressure/height/state-vector
inputs. This made it difficult to reproduce avionics-style event logic that
depends on acceleration profiles.
What this PR changes
This PR adds first-class support for acceleration-aware trigger callables by
passing state derivatives (
u_dot) to user-defined trigger functions.1) Trigger callable signatures support
u_dotIn
rocketpy/rocket/parachute.py, callable dispatch supports:3 args:(pressure, height, state_vector)4 args:(pressure, height, state_vector, u_dot)or(…, sensors)5 args:(pressure, height, state_vector, sensors, u_dot)Dispatch is deterministic, and trigger wrappers expose metadata
(
_expects_udot,_expects_sensors) used byFlight.2)
Flightcomputesu_dot(t, y)inside trigger evaluation when neededIn
rocketpy/simulation/flight.py, trigger checks consistently route through_evaluate_parachute_trigger(...), andu_dotis computed only when requiredby trigger metadata.
This follows the architecture discussed in Issue #156: acceleration is not in
the solver state vector and must be obtained from derivative evaluation at the
event-check instant.
3) Docs now include acceleration-based trigger examples
docs/user/parachute_triggers.rstwas updated with custom trigger examples for:Thresholds are intentionally mission-specific and configurable by users.
4) Final API scope from review
Per review direction, this PR keeps the API focused on custom callables and
does not introduce acceleration-specific built-in trigger strings.
Acceptance criteria coverage (Issue #156)
Flightto calculateu_dotinside event checking flowu_dot) to user-defined triggersFiles changed
rocketpy/rocket/parachute.pyu_dot/sensor-aware trigger wrapper behaviorrocketpy/simulation/flight.pyu_dotcomputationdocs/user/parachute_triggers.rsttests/unit/test_parachute_triggers.pyu_dotdeliverytests/unit/test_parachute_trigger_acceleration.pyBreaking change
No breaking change in trigger usage: existing numeric,
"apogee", and legacy3-argument callables remain supported.
Validation performed
blackrun on modified Python filespytest tests/unit/test_parachute_triggers.py -qpassingRelated issue