Repository navigation
ENH: Acceleration data to trigger parachutes #156
Description
Activity
@FranzYuri can you please take a look at this since it's releated to parachute functions? I think you'll like it!!
Might not be too complicated, but let's use some minutes during the week to discuss if needed
@MateusStano, these may help you:
7 remaining items
Hi @giovaniceotto ! I'm interested in working on this issue for the recruitment process.
Since I work with embedded systems in my rocketry team, adding acceleration-based triggers feels very relevant to me (especially because we actually faced issues with our parachute triggering during the last LASC).
I am currently analyzing
flight.pyto understand the best way to access the acceleration data (fromu_dot) and pass it to the parachute triggers.Let me know if I can proceed with this!
Hi @giovaniceotto ! I'm interested in working on this issue for the recruitment process.
Since I work with embedded systems in my rocketry team, adding acceleration-based triggers feels very relevant to me (especially because we actually faced issues with our parachute triggering during the last LASC).
I am currently analyzing
flight.pyto understand the best way to access the acceleration data (fromu_dot) and pass it to the parachute triggers.Let me know if I can proceed with this!
Hello @ViniciusCMB I will try to guide you with these.
Since this issue was raised, a lot has already changed in this lib. It's possible that we no longer need to solve this one. I need to read it more carefully through the weekend and then get back to you asap.
Thanks for the heads-up!
I understand, a lot changes in 3 years. I will wait for your feedback after the weekend then.
In the meantime, I might take a look at other "good first issues" just to familiarize myself with the codebase and maybe tackle something else if this one turns out to be deprecated.
Looking forward to hearing from you.
Reacted by Gui@ViniciusCMB way to go!!
Easy PRs are: #725, #656, and #242
I will try to update every issue on our repo in the next few weeks.
@ViniciusCMB , I reviewed the architecture. This is not deprecated, it is actually a very important feature for simulating realistic avionics. The challenge is that you need to calculate u_dot(t, y) inside the event loop to get the acceleration. I have updated the issue description with the technical details.
In case you want to read a more detailed description, here it goes:
This is a critical feature for advanced users. It is definitely still necessary.
Here is the breakdown of why, how to solve it, and the updated issue description.1. Is this still necessary? YES.
Why?
Real-world rocket avionics (flight computers) rarely use "altitude" or "vertical velocity" directly to detect events because barometers are noisy and GPS is slow.
Most avionics trigger events based on Accelerometer data (IMU):- Liftoff detection: High positive acceleration.
- Burnout detection: Sudden drop in acceleration.
- Apogee detection: 0 velocity (integrated from acceleration).
Currently, RocketPy forces users to trigger parachutes based on state variables (Position
z, Velocityvz) or Pressure. This is "God Mode" simulation. To simulate realistic avionics logic, the user needs access toacceleration(and ideally, noisy acceleration) inside the trigger function.2. How can we do this?
The Problem:
RocketPy usesscipy.integrate.solve_ivp.- The solver passes
(t, y)(Time and State Vector) to the Event/Trigger function. - Acceleration is NOT in the State Vector
y(which is[x, v, ...]). - Acceleration is the derivative
y'(oru_dot).
The Solution:
To get acceleration inside the trigger, we must calculate the derivative inside the event function.- Current Flow:
Trigger(pressure, state_vector) - New Flow:
Inside the internal wrapper that RocketPy uses for events:def parachute_trigger_wrapper(t, y): # 1. Calculate the physics derivative at this exact moment # This gives us [vx, vy, vz, ax, ay, az, ...] u_dot = flight.u_dot(t, y) # 2. Extract acceleration acc_z = u_dot[5] # (assuming index 5 is az) # 3. (Optional) Add Sensor Noise here if strictly required # 4. Call the user's trigger function with extra data return user_trigger_function(pressure, y, acceleration=acc_z)
Trade-off: This adds computational cost (physics is calculated twice: once for the step, once for the event check). However, this is the only accurate way to do it.
Hi @Gui-FernandesBR!
I have just submitted PR #911 addressing this issue.
The PR implements the logic to expose acceleration (u_dot) to parachute triggers, enabling realistic avionics simulation. It includes:
New Built-in Triggers: apogee_acc, detect_motor_burnout, detect_liftoff, and detect_freefall.
IMU Simulation: Added acceleration_noise_function to the Flight class to simulate sensor noise.
Optimization: The simulation only calculates u_dot inside the event loop if the trigger signature explicitly requests it, preventing performance drops for legacy triggers.
Backward Compatibility: Fully supports existing 3-parameter triggers.
Looking forward to your review!
Reacted by Gui- linked a pull request that will close this issueENH: acceleration data to trigger parachutes #911
on Dec 9, 2025
Is your feature request related to a problem? Please describe.
Currently, custom functions used to trigger parachutes (events) only have access to Pressure and the State Vector (position, velocity, attitude, angular rates).
However, real-world flight computers (avionics) heavily rely on Accelerometers (IMU) to detect flight phases (e.g., Liftoff, Motor Burnout, Apogee).
Because RocketPy does not expose acceleration to the trigger, users cannot simulate these realistic avionics algorithms.
Describe the solution you'd like
I would like to update the
Flightclass event handling logic to pass acceleration data to the parachute trigger callbacks.The trigger signature should ideally support:
Implementation Details
rocketpy/flight/flight.pyscipy.integrate), we need to explicitly callself.u_dot(t, y)to obtain the current derivatives.u_dotinside the event checker effectively doubles the physics load for event detection. This is acceptable for the gained accuracy, but we should document it.Acceptance Criteria
Flightclass to calculateu_dotinside the event checking loop.u_dot) to the user-defined trigger function.Additional Context
ycontains[x, y, z, vx, vy, vz, ...].[ax, ay, az]is only available after computing the derivativeu_dot.