[MateusStano]

Pull request type

• Code changes (bugfix, features)

Checklist

• Tests for the changes have been added (if needed)
• Lint (ruff) has passed locally
• Flight, simulation and acceptance tests have passed locally
• CHANGELOG.md — no action needed; an LLM workflow auto-updates it after merge

Current behavior

Flight.u_dot, the "solid_propulsion" equations of motion, zeroes the angular rates right after unpacking the state:

_, _, z, vx, vy, vz, e0, e1, e2, e3, omega1, omega2, omega3 = u
omega1, omega2, omega3 = 0, 0, 0

So the aerodynamics (every surface's forces and moments, the rate-dependent drag inputs, the ω × r term of each surface's local airspeed) and the Euler equations see a rocket that never rotates. There is no aerodynamic damping at all: a pitch rate produces no restoring moment, and a canted fin spins the rocket up without bound.

Every rocket with a SolidMotor is mapped to these equations automatically, so every such 6-DOF flight has been affected. The line was introduced with the 3-DOF work in #745; before it, u_dot used the real rates.

On Calisto with 5–15 m/s wind, apogee-terminated:

	before	after	u_dot_generalized
max pitch rate	12.0 rad/s	0.13 rad/s	0.12 rad/s
max roll rate, 1.5° cant	1035 rad/s	38.4 rad/s	38.5 rad/s
apogee	4729 m	4643 m	4632 m
position at apogee (x, y)	(303, 366) m	(−585, 568) m	(−654, 569) m

New behavior

The line is removed. The solid-propulsion equations now agree with the generalized ones to ~0.25 % on apogee and ~0.2 % on roll rate, which is the genuine modelling difference between them (two-body mass model and axisymmetric inertia versus the full tensor).

Why the suite never caught it: no test asserted anything about rotation (test_rolling_flight only checked all_info()), the hard-coded expected values are sampled at rail exit, apogee and landing where the rates are zero anyway, the fixture environments have no wind so there is no angle of attack to damp, and the two sets of equations were never compared. The new tests close those gaps:

• test_an_angular_rate_is_aerodynamically_damped (unit, both derivatives): a rate about each body axis, on a coasting state, produces an angular acceleration that opposes it, roughly linearly.
• test_solid_propulsion_and_generalized_equations_agree_when_rotating (unit): with a pitch rate applied, both models give the same damping moment and accelerations.
• test_solid_propulsion_equations_damp_rotation (integration): a 1.5° canted-fin Calisto reaches the same roll rate with either model, and stays under 100 rad/s.
• test_rolling_flight now asserts the roll rate is bounded and tracks the airspeed through the coast.

With the bug re-introduced, the three tests that exercise u_dot fail.

Breaking change

• No

Results of solid-motor 6-DOF flights change, since they are now damped: apogee moves by a percent or so on Calisto, and any quantity involving rotation (roll rate, angular accelerations, sensor readings on gyroscopes) changes substantially. The acceptance tests against real flight data still pass.

Additional information

Found while comparing u_dot and u_dot_generalized line by line for a review question on #968. The same fix is applied on enh/events.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.59%. Comparing base (a50d07d) to head (f3c0c86).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1195      +/-   ##
===========================================
+ Coverage    91.58%   91.59%   +0.01%     
===========================================
  Files          132      132              
  Lines        18404    18403       -1     
===========================================
+ Hits         16855    16857       +2     
+ Misses        1549     1546       -3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Gui-FernandesBR]

The fix is right: it restores u_dot exactly as it was before #745. The three u_dot tests fail on develop (a50d07d5) and pass here, and pytest tests -m "not slow" plus the acceptance tests pass locally. One correction to the description, and two old bugs in u_dot that this PR makes live again.

1. Scope. equations_of_motion defaults to "standard" (u_dot_generalized), and nothing picks solid_propulsion automatically. So only flights that opt in were affected (v1.12.0 to v1.13.0), not every SolidMotor flight. None of the acceptance tests opts in, so they don't cover this change. The zeroing also froze the attitude (e0dot..e3dot were 0), not only the aero. The changelog entry will be written from this description, so it's worth fixing.

2. Linear acceleration, wrong axis. The transport terms in L2450-2465 treat the propellant offset b as lying on body axis 1, but it lies on axis 3 (the thrust axis). On flight_calisto_robust at t = 1.5 s (m_p = 1.57 kg), a pure roll of ω3 = 20 rad/s gives u_dot a lateral body acceleration of −30.3 m/s², while u_dot_generalized gives none. With the offset on axis 3 and the same sign convention, the terms are b·m_p·(α2 + ω1ω3), b·m_p·(−α1 + ω2ω3) and −b·m_p·(ω1² + ω2²).

3. Inertia rate, wrong units. mass_flow_rate * (rocket_dry_mass - 1) * (b / total_mass) ** 2 (L2403, L2428) is dimensionally inconsistent. Since d(μb²)/dt = ṁ·b²·(m_r/M)², it should read rocket_dry_mass**2.

Neither 2 nor 3 blocks this PR, since without it the rocket doesn't rotate at all. Fixing them here or in a follow-up is your call.

[Gui-FernandesBR]

This flight runs with the default equations_of_motion="standard", so it also passes on develop and doesn't guard this fix. It's still useful coverage of u_dot_generalized.

[Gui-FernandesBR]

In the coast m_p = 0, so every b·m_p coupling term vanishes and this test can't see the axis bug in the linear acceleration (point 2 in the review). A burn-phase case would catch it once it's fixed, e.g. t = 1.5 s with ω3 = 20 rad/s.