Describe the bug
In IsaacLab main/ v2.3.2, the IMU linear and angular accelerations are computed by finite differencing the previous sensor buffer with self._dt:
lin_acc_w = (lin_vel_w - self._prev_lin_vel_w[env_ids]) / self._dt + self._gravity_bias_w[env_ids]
ang_acc_w = (ang_vel_w - self._prev_ang_vel_w[env_ids]) / self._dt
However, self._dt is the scene physics step, while the IMU buffer is only refreshed when the sensor becomes outdated:
self._is_outdated |= self._timestamp - self._timestamp_last_update + 1e-6 >= self.cfg.update_period
So when update_period > physics_dt, the velocity difference spans the sensor refresh interval, but the denominator is still the smaller physics step. This inflates the reported acceleration by approximately update_period / physics_dt.
Example:
- physics_dt = 0.005
- imu.update_period = 0.02
Then the velocity delta spans about 0.02s, but the code divides by 0.005s, producing roughly 4x too large acceleration.
This affects imu_lin_acc directly, and imu_ang_acc as well.
For the 3.0 beta PhysX IMU, the exact old Python line is gone, but the same linear-acceleration risk still exists in equivalent form:
isaaclab_physx/sensors/imu/kernels.py computes:
lin_acc_w = (lin_vel_w - prev_lin_vel_w[idx]) * inv_dt + gravity_bias_w[idx]
Steps to reproduce
Minimal example:
imu_cfg.update_period = 0.02
physics_dt = 0.005
Run a simulation where the body velocity changes smoothly over time, then inspect the IMU output after each sensor update. The reported acceleration will be scaled as if the velocity change happened over physics_dt instead of the actual sensor interval.
A simple reproduction is to log the IMU output across several physics steps and compare it against finite differences over the real sensor update interval. When update_period > physics_dt, the IMU acceleration is consistently too large.
Expected behavior:
IMU acceleration should be computed using the actual elapsed time between the two velocity samples used in the finite difference, not the last scene physics dt.
Actual behavior:
Acceleration is overestimated whenever the IMU update period is larger than the physics step.
System Info
Describe the characteristic of your environment:
- Commit: b0542fe
- Isaac Sim Version: 2.3.2
- OS: Ubuntu 22.04
- GPU: RTX 3080
- CUDA: 13.0
- GPU Driver: 580.173.02
Additional context
I also checked the 3.0 beta PhysX IMU implementation. The exact Python line is gone there, but the same issue still exists in equivalent form:
- self._dt = dt
- 1.0 / self._dt is passed into the Warp kernel
- the kernel computes lin_acc_w = (lin_vel_w - prev_lin_vel_w[idx]) * inv_dt + gravity_bias_w[idx]
So the same mismatch remains if update_period > physics_dt.
Separately, there is also a reset-related spike risk because the previous velocity buffer is initialized to zero, but that is a different issue from the time-domain mismatch above.
Checklist
Acceptance Criteria
Describe the bug
In IsaacLab main/ v2.3.2, the IMU linear and angular accelerations are computed by finite differencing the previous sensor buffer with self._dt:
lin_acc_w = (lin_vel_w - self._prev_lin_vel_w[env_ids]) / self._dt + self._gravity_bias_w[env_ids]
ang_acc_w = (ang_vel_w - self._prev_ang_vel_w[env_ids]) / self._dt
However, self._dt is the scene physics step, while the IMU buffer is only refreshed when the sensor becomes outdated:
self._is_outdated |= self._timestamp - self._timestamp_last_update + 1e-6 >= self.cfg.update_period
So when update_period > physics_dt, the velocity difference spans the sensor refresh interval, but the denominator is still the smaller physics step. This inflates the reported acceleration by approximately update_period / physics_dt.
Example:
Then the velocity delta spans about 0.02s, but the code divides by 0.005s, producing roughly 4x too large acceleration.
This affects imu_lin_acc directly, and imu_ang_acc as well.
For the 3.0 beta PhysX IMU, the exact old Python line is gone, but the same linear-acceleration risk still exists in equivalent form:
isaaclab_physx/sensors/imu/imu.pysets:self._dt = dt
It passes:
1.0 / self._dt
into the Warp kernel.
isaaclab_physx/sensors/imu/kernels.pycomputes:lin_acc_w = (lin_vel_w - prev_lin_vel_w[idx]) * inv_dt + gravity_bias_w[idx]
Steps to reproduce
Minimal example:
imu_cfg.update_period = 0.02
physics_dt = 0.005
Run a simulation where the body velocity changes smoothly over time, then inspect the IMU output after each sensor update. The reported acceleration will be scaled as if the velocity change happened over physics_dt instead of the actual sensor interval.
A simple reproduction is to log the IMU output across several physics steps and compare it against finite differences over the real sensor update interval. When update_period > physics_dt, the IMU acceleration is consistently too large.
Expected behavior:
IMU acceleration should be computed using the actual elapsed time between the two velocity samples used in the finite difference, not the last scene physics dt.
Actual behavior:
Acceleration is overestimated whenever the IMU update period is larger than the physics step.
System Info
Describe the characteristic of your environment:
Additional context
I also checked the 3.0 beta PhysX IMU implementation. The exact Python line is gone there, but the same issue still exists in equivalent form:
So the same mismatch remains if update_period > physics_dt.
Separately, there is also a reset-related spike risk because the previous velocity buffer is initialized to zero, but that is a different issue from the time-domain mismatch above.
Checklist
Acceptance Criteria