Skip to content

feat: Normalize IMU data and use buffers for IMU's - #612

Draft
pastaq wants to merge 1 commit into
mainfrom
pastaq/imu_refactor
Draft

feat: Normalize IMU data and use buffers for IMU's#612
pastaq wants to merge 1 commit into
mainfrom
pastaq/imu_refactor

Conversation

@pastaq

@pastaq pastaq commented Jun 20, 2026

Copy link
Copy Markdown
Contributor

This PR does a major overhaul of how IMU data is managed across every aspect of InputPlumber.

  • All source device drivers now normalize IMU data into radians per second for gyroscope data and meters per second squared for accelerometer data.
  • All target devices now denormalize Accelerometer and Gyroscope events into their native format (typically LSB).
  • The iio_imu source device driver now configures a buffer and follows an asynchronous drain/refill pattern to create events. This reduces CPU and RAM overhead by reducing the number of reads per event from 3-6 to 1. This also has the benefit of reducing jitter when using iio_imu based devices as the entire event is now based on a single timestamp, when the old method had significant drift during each poll.

@pastaq
pastaq force-pushed the pastaq/imu_refactor branch 2 times, most recently from 02b9181 to 208de6a Compare June 21, 2026 05:37
@pastaq
pastaq force-pushed the pastaq/imu_refactor branch from 208de6a to 5708e71 Compare August 21, 2026 18:51
This PR does a major overhaul of how IMU data is managed across every
aspect of InputPlumber.
- All source device drivers now normalize IMU data into radians per second
  for gyroscope data and meters per second squared for accelerometer data.
- All target devices now denormalize Accelerometer and Gyroscope events
  into their native format (typically LSB).
- Split BMI and AccelGyro3D Drivers. The AccelGyro3D source device driver
  now configures a buffer and follows an asynchronous drain/refill pattern
  to create events. This reduces CPU and RAM overhead by reducing the
  number of reads per event from 3-6 to 1. This also has the benefit of
  reducing jitter when using AccelGyro3D based devices as the entire event
  is now based on a single timestamp, when the old method had significant
  drift during each poll.
- Removes deprecated Gamepad::Accelerometer and Gamepad:Gyro events.
@pastaq
pastaq force-pushed the pastaq/imu_refactor branch from 5708e71 to 041db89 Compare August 21, 2026 18:57
@ilyasturki

Copy link
Copy Markdown

I hit the DS5 accelerometer saturation this PR fixes: the hidraw source forwards raw counts, denormalize_accel_value scales them a second time, the i16 saturates, and the emulated pad has no usable gravity vector left.

Reading the new constants, the forward direction looks right but the inverses look wrong. Each pair should round-trip to 1 and neither does:

DS5_ACCEL_TO_SI  × DS5_SI_TO_ACCEL  = 0.00119710083 × 0.101971621 = 1/8192
DS5_GYRO_TO_RADS × DS5_RADS_TO_GYRO = 0.00001706026 × 57.29577951 ≈ 1/1024

Raw to SI to raw loses the resolution factor each time.

constant value equals verdict
DS5_ACCEL_TO_SI 0.00119710083 9.80665 / 8192, raw to m/s² correct
DS5_SI_TO_ACCEL 0.101971621 1 / 9.80665, m/s² to G should be 835.352 = 8192 / 9.80665
DS5_GYRO_TO_RADS 0.00001706026 (π/180) / 1024, raw to rad/s correct
DS5_RADS_TO_GYRO 57.29577951 180 / π, rad/s to deg/s should be 58670.9 = 1024 · 180/π

The driver applies the forward constants as raw to SI (state.accel_x.to_primitive() as f64 * DS5_ACCEL_TO_SI), so nothing compensates further down. As written denormalize_accel_value(9.80665) returns 1 where the target's own calibration report advertises 8192, and the gyro path is off by the same 1024.

denormalize_gyro_value also still takes value_degrees_sec while its doc comment now says radians per second.

I have DualSense Edge hardware on Bluetooth and USB. I can test the branch and send the constant fix as a PR against it.

@pastaq

pastaq commented Sep 2, 2026

Copy link
Copy Markdown
Contributor Author

Awesome, thanks. This PR is kinda stuck at the moment but I plan to break it up into a few separate PR's. I haven't gone through to validate all the value changes, I think I made quite a few mistakes. I'll be sure to review your input here when I'm working on the SI standardization piece.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants