Use solver-reported accelerations and track runtime gravity in PhysX and OvPhysX IMU/PVA sensors

[AntoineRichard]

Description

Three related defects in the IMU and PVA sensors, across PhysX and OvPhysX. They were originally split across this PR and #7538 (now closed as superseded); they are combined here because they touch the same kernels and could not be reviewed or merged independently.

1. Accelerations were finite-differenced (#1294)

Both sensors computed linear acceleration by finite-differencing body velocity between updates. This made the reading depend on the sensor update period, produced a zero or stale reading on the first update, and generated large spurious spikes whenever velocities were written directly (resets, teleports).

PhysX: the sensors now read RigidBodyView.get_accelerations() and transport it to the sensor frame as a_sensor = a_com + α×r + ω×(ω×r). The IMU adds the gravity bias; PVA does not, since PVA reports kinematic acceleration.

OvPhysX: the sensors read accelerations through the RIGID_BODY_ACCELERATION tensor binding with the same transport math. An earlier revision of this PR guarded that behind hasattr(TT, "RIGID_BODY_ACCELERATION") and fell back to finite differencing, because the binding had not shipped yet. It has since shipped and the project pins ovphysx==0.5.11 exactly, so the fallback was unreachable on every supported install and has been removed along with its duplicate kernels and previous-velocity state.

This also aligns PhysX and OvPhysX with Newton, whose PVA already computed acceleration from body_qdd with exactly this transport.

get_accelerations() accuracy

Verified on Isaac Sim 6.0.1 with a constant applied force (expected a = F/m):

mass	solver acc	expected	rel. err
1 kg	0.00199992	0.002	0.004%
1 g	2.00004	2.0	0.002%
1 µg	2000.0	2000.0	<0.001%

The historical small-mass inaccuracy that motivated the finite-difference implementation is no longer present.

2. OvPhysxManager.get_gravity() returned a stale value

set_gravity() authored the new gravity into OvStage and applied it to the running simulation, but get_gravity() read SimulationCfg.gravity, which the setter never touched. Every call after a live update returned the construction-time value, silently and permanently:

get_gravity before set : (0.0, 0.0, -9.81)
set_gravity called with: (0.0, 0.0, -3.72)
get_gravity after  set : (0.0, 0.0, -9.81)

The manager now tracks the applied gravity rather than writing back to cfg.gravity. Writing back would have been wrong: both _call_physx and _call_ovphysx in randomize_physics_scene_gravity resample from env.sim.cfg.gravity as the pristine base, so mutating it would make successive "add"/"scale" randomizations compound.

3. Sensors snapshotted gravity at initialization

IMU and PVA read gravity once in _initialize_impl and baked it into a static buffer, so gravity randomized at runtime never reached the accelerometer bias or the projected gravity direction. This affected both backends and was independent of defect 2 — fixing get_gravity() alone would not have changed sensor behavior.

Both sensors now re-read scene gravity on every update, skipping the work when it is unchanged. This matters more after change 1, not less: the IMU reading is now literally solver_a + (−g), so a stale g enters as a clean additive bias. Randomizing to Mars gravity made a resting body read +9.81 instead of +3.72 — a systematic 6.09 m/s² offset on every sample.

Gravity is scene-wide on both backends, so the bias and the gravity direction are passed to the kernels by value rather than as per-body buffers. The PhysX recorded launches re-bind the parameter with set_param_by_name when it changes, mirroring how env_mask is already handled. If per-env gravity ever reaches these backends these go back to arrays, as Newton already does.

Breaking change

The PhysX PVA sensor's GRAVITY_VEC_W proxy array becomes the internal _gravity_vec_w scene-wide vector, matching what the OvPhysX PVA sensor already called it. It was absent from the data class, the type stubs and the docs. Consumers wanting this quantity should read pva_sensor.data.projected_gravity_b. The identically-named attribute on the asset data classes is untouched.

Known remaining gaps (not addressed here)

• GRAVITY_VEC_W is still snapshotted at construction in the asset data classes (rigid_object_data.py, rigid_object_collection_data.py, articulation_data.py) for both backends. Newton fixed its three by binding ProxyArray(model.gravity[:world_count]) zero-copy, which is not possible here: OvPhysX exposes no scene-gravity tensor binding, and PhysX exposes gravity only as a host-side Float3. A fix must use the same pull-based refresh used here, and first needs a decision on whether to converge PhysX/OV onto Newton's m/s² convention (they currently store a normalized direction), which would touch consumers in isaaclab_experimental and isaaclab_tasks_experimental.
• Newton's Imu applies no gravity bias at all, unlike the PhysX and OvPhysX IMUs. This looks like a cross-backend behavioral gap rather than a staleness bug.

Fixes #1294

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Breaking change (existing functionality will not work without user modification)
• Documentation update

Release backport

• Backport this pull request to the active release branch after it merges into develop

Screenshots

Not applicable — no visual change.

Checklist

Docker and GPU tests run on demand. Push the commits you want tested, then
comment run-ci on the pull request.

• I have read and understood the contribution guidelines
• I have run the pre-commit checks with ./isaaclab.sh --format
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• I have added a changelog fragment under source/<pkg>/changelog.d/ for every touched package (do not edit CHANGELOG.rst or bump extension.toml — CI handles that)
• I have added my name to the CONTRIBUTORS.md or my name already exists there

Testing

All suites run locally, one file at a time:

Suite	Result
isaaclab_physx IMU	11 passed
isaaclab_physx PVA	11 passed
isaaclab_physx recorded-launch	13 passed
isaaclab_ov IMU (default / -k cuda)	12 passed, 14 skipped / 12 passed
isaaclab_ov PVA (default / -k cuda)	13 passed, 15 skipped / 13 passed
isaaclab_ov physics	53 passed

Regression coverage, each verified to fail without its fix:

• test_set_gravity_writes_and_releases_ovstage_control_resources — asserts get_gravity() round-trips after a successful set_gravity(), still reports the previously applied value when the OvStage write fails, and leaves cfg.gravity untouched as the randomization base. Without the fix: assert (0.0, 0.0, -9.81) == approx((0.0, 0.0, -3.72)), reproducing the reported symptom.
• test_sensor_tracks_runtime_gravity_changes and test_imu_replayed_launch_applies_new_gravity_bias — a mid-run gravity change must reach the replayed recorded launch, with an explicit guard that the test is on the recorded path rather than the eager fallback.
• test_velocity_writes_do_not_produce_spurious_acceleration (IMU and PVA) — velocity teleports must not produce an acceleration spike. Without the fix the PVA case fails with a 99.9998 difference, exactly the 0.1 / dt = 100 m/s² finite-difference artifact.

The OvPhysX IMU tests were updated where they encoded finite-difference artifacts as expected values — most notably test_gravity_at_rest, whose old scenario never had the ball at rest (it fell continuously while zero velocity was rewritten each step). It now applies a real support force so the body is genuinely at rest and the accelerometer reads the bias alone, as a real IMU on a table does.

[greptile-apps]

Greptile Summary

The PR replaces finite-difference IMU acceleration with solver-reported COM acceleration and transports it to the configured sensor frame, while retaining an OVPhysX fallback for older wheels.

• Adds solver-acceleration kernels for PhysX and OVPhysX IMUs.
• Adds acceleration-buffer handling to the PhysX recorded-launch path.
• Reworks PhysX tests around applied forces and direct velocity writes.
• The OVPhysX optional-binding selection does not currently handle a present-but-unavailable binding.

Confidence Score: 4/5

The OVPhysX fallback should be corrected before merging because a wheel with an exposed but unusable acceleration binding can prevent the IMU from initializing.

The solver-acceleration transport is consistent with repository spatial-vector and COM conventions, but optional OVPhysX capability handling calls a raising binding API before the documented finite-difference fallback can be selected.

Files Needing Attention: source/isaaclab_ov/isaaclab_ov/sensors/imu/imu.py

Important Files Changed

Filename	Overview
source/isaaclab_ov/isaaclab_ov/sensors/imu/imu.py	Adds runtime solver-acceleration selection, but checks enum presence rather than whether the optional tensor binding can actually be acquired.
source/isaaclab_ov/isaaclab_ov/sensors/imu/kernels.py	Adds COM-to-sensor acceleration transport using the OV tensor’s documented linear-first spatial layout.
source/isaaclab_physx/isaaclab_physx/sensors/imu/imu.py	Integrates the acceleration view into eager and recorded updates, including pointer-stability validation and invalidation.
source/isaaclab_physx/isaaclab_physx/sensors/imu/kernels.py	Replaces elapsed-time velocity differencing with solver acceleration and rigid-body transport terms.
source/isaaclab_physx/test/sensors/test_imu.py	Updates behavior tests to validate force-derived acceleration and suppression of velocity-write spikes.
source/isaaclab_physx/test/sensors/test_imu_pva_recorded_launch.py	Extends recorded-launch fixtures and assertions to cover stable acceleration buffers and refreshed acceleration values.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    Step[Physics step] --> Solver[Solver-reported COM acceleration]
    Solver --> PhysX[PhysX IMU kernel]
    Solver --> Capability{OV acceleration binding usable?}
    Capability -->|Yes| OVKernel[OV solver-acceleration kernel]
    Capability -->|No| Fallback[OV finite-difference kernel]
    PhysX --> Transport[Transport COM acceleration to sensor offset]
    OVKernel --> Transport
    Transport --> Output[Body-frame IMU acceleration plus gravity bias]

Loading

_{Reviews (1): Last reviewed commit: "Use solver-reported accelerations in Phy..." | Re-trigger Greptile}

[isaaclab-review-bot]

Isaac Lab Review Bot

Reviewed the PhysX and OvPhysX IMU transition from velocity finite-differencing to solver-reported accelerations, including center-of-mass transport, gravity bias, buffer caching, recorded launches, fallback behavior, tests, and release notes. No candidate findings were supplied or supported for posting.

• Design and architecture: The backend split is coherent: PhysX uses RigidBodyView.get_accelerations(), while OvPhysX selects the solver path only when RIGID_BODY_ACCELERATION is exposed and otherwise retains the finite-difference path. PVA behavior remains separate and unchanged.
• API: The existing ImuData.lin_acc_b shape and body-frame convention are preserved, while its PhysX semantics intentionally become independent of sensor update period and direct velocity writes. Both affected packages include changelog fragments, and the OvPhysX documentation describes its version-dependent behavior.
• Implementation: The new acceleration buffers are connected consistently through acquisition, typed views, pointer-stability checks, kernel launches, and invalidation. Both kernels apply the documented COM-to-sensor transport terms and gravity bias. PhysX regression and recorded-launch coverage were updated; the residual validation gap is that the new OvPhysX solver-binding path was wheel-skipped locally.

No blocking issues. No inline issue met the actionable-evidence threshold; the assessment above records the review feedback.

Automated review; human maintainers own approval decisions.

[kellyguo11]

run-ci

[kellyguo11]

run-ci

[kellyguo11]

run-ci

[isaaclab-bot]

Backported to release/3.0.0 as fa92933.