[carlo98]

• Tickets addressed: imuSensor reports a spurious delta v when the spacecraft rotates #1619
• Review: By file
• Merge strategy: Merge (no squash)

Description

imuSensor computation of DVFramePlatform assumes that TotalAccumDV_BN_B is the inertial accumulated
delta-v resolved in the current body frame. spacecraft instead adds the delta-v of each integration step in the body frame of that step (Spacecraft::postIntegration()), and test_spacecraft.py checks that this is how the field is built. As a result, every attitude change between two IMU calls added (I - [BN]_2 [NB]_1) A_1, a term proportional to all the delta-v accumulated since the start of the simulation, to the output.

The module now computes the documented quantity from fields that spacecraft already writes:

DV_SN_N = Delta TotalAccumDV_CN_N + Delta (v_BN_N - v_CN_N + [NB] omega_BN_B x r_SB_B)
DVFramePlatform = [PB][BN]_2 DV_SN_N

The first term is the non-gravitational delta-v of the center of mass, accumulated in inertial components. The second term is the change of the sensor velocity relative to the center of mass. The output no longer depends on the attitude at the previous call.

Alternatives considered and rejected:

• Adding a TotalAccumDV_BN_N field to SCStatesMsgPayload: gives the same numbers, but changes a message payload and every producer.
• Redefining TotalAccumDV_BN_B in spacecraft: changes a published field and breaks the existing spacecraft test.
• Integrating nonConservativeAccelpntB_B in the IMU: only correct when the IMU runs at the dynamics rate.

While checking the producers of SCStatesMsgPayload, two related issues were found:

• MJSite::writeFwdKinematicsMessage() did not initialize the payload. Its documentation only declares the position, velocity, attitude and angular rate of the site, so the other fields are now zero.
• spacecraft did not initialize nonConservativeAccelpntB_B and omegaDot_BN_B. They held uninitialized values in the message written before the first integration step and, with pointMassTranslationalOnly, during the whole simulation. They are now zero until computed.
• imuSensor::Reset() kept the state of the previous IMU call. This was already the case before, but the previous state now also includes the delta-v and the sensor velocity relative to the center of mass. The first call after a reset in the middle of a simulation differenced the new state against the state from before the reset. Reset() now clears NominalReady, so this call outputs a zero message, as the first call of a simulation does.

Messages not written by spacecraft must now fill TotalAccumDV_CN_N, v_BN_N and v_CN_N consistently.

Verification

• The issue's minimal case returned [1.52, 17.36, 0.0] m/s before the fix. It is now in the unittests.
• New unittests.
• Past unittests pass.

Documentation

• imuSensor.rst: new "Delta-v Output" section with the formula, the required input fields, and the limitations.
• _Documentation/secModelDescription.tex: rewritten "Change In Velocity" derivation.
• MJSite.h: writeFwdKinematicsMessage() documents that the fields a site does not provide are zero.
• bskKnownIssues.rst entries and release-note snippet.

Future work

• spacecraft with pointMassTranslationalOnly does not accumulate delta v: postIntegration() returns early and the gravity-velocity states are not registered. TotalAccumDV_* and nonConservativeAccelpntB_B stay zero under thrust, so the IMU delta v and acceleration are zero in this mode. Check whether this is wanted.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	⚠️ Failed 2026-10-17T08:40:53.085549Z	cc4324f	PR opened

ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[schaubh]

I agree with issue #1619 and the core fix. The minimal reproduction returned [1.5192, 17.3648, 0] m/s before rebuilding and [0, 0, 0] on this PR. The affected targets and isolated IMU header compiled, and 90 focused IMU, spacecraft, and MuJoCo tests passed. I found no blocking functional defect; the two inline comments identify documentation corrections.