Start with the why
We use an OAK-D Pro W as a stereo camera and IMU source for a VIO pipeline on a vibration-prone mobile platform. The device reports high-rate raw accelerometer and gyroscope data, but motor vibration can occupy approximately 70-220 Hz. A sensor-side bandwidth limit applied before reporting/timestamping could prevent aliasing and avoid the variable phase and timing discontinuities introduced by host-side filtering.
Hardware and software checked:
- OAK-D-PRO-W-97, board DM9098 R8M2E8
- Connected IMU: BNO086
- Running and embedded BNO086 firmware: 3.9.9
- depthai-core / Python: 3.7.1
We also checked depthai-core 3.8.0 and current main/develop. IMUSensorConfig exposes sensitivity fields, reportRate, and sensorId, but no accelerometer/gyroscope LPF, bandwidth, or anti-alias setting.
The BNO08X datasheet says SH-2 algorithms apply bandwidth-limiting filtering and therefore add delay. The public SH-2 driver also contains a sensorSpecific word in Set Feature, but DepthAI does not expose it and we could not find documentation showing that it controls raw accelerometer/gyroscope bandwidth.
Move to the what
Could Luxonis clarify the exact behavior of ACCELEROMETER_RAW and GYROSCOPE_RAW on BNO086 firmware 3.9.9?
- What physical accelerometer and gyroscope ODR and pre-report bandwidth does SH-2 configure?
- Is filtering applied before the timestamp associated with each raw report, and what is the transfer function or measured group delay?
- Is there any currently supported DepthAI API or device firmware configuration for selecting the raw accelerometer/gyro LPF or anti-alias bandwidth?
- Does the SH-2
sensorSpecific Set Feature word support bandwidth selection for these raw reports on BNO086?
- If the configuration is fixed, can Luxonis document the cutoff/bandwidth and latency used by firmware 3.9.9?
Move to the how
If BNO086 firmware supports a safe bandwidth selection, please expose it as explicit optional fields in IMUSensorConfig, with per-IMU validation and readback of the effective configuration. It would also be useful to document whether changing reportRate changes only the report interval or also changes the physical sensor ODR/filter configuration.
We are not requesting raw register access or an undocumented firmware workaround. A fail-closed, vendor-supported API plus documented delay/frequency response is required before this could be used in a VIO production path.
Start with the why
We use an OAK-D Pro W as a stereo camera and IMU source for a VIO pipeline on a vibration-prone mobile platform. The device reports high-rate raw accelerometer and gyroscope data, but motor vibration can occupy approximately 70-220 Hz. A sensor-side bandwidth limit applied before reporting/timestamping could prevent aliasing and avoid the variable phase and timing discontinuities introduced by host-side filtering.
Hardware and software checked:
We also checked depthai-core 3.8.0 and current main/develop.
IMUSensorConfigexposes sensitivity fields,reportRate, andsensorId, but no accelerometer/gyroscope LPF, bandwidth, or anti-alias setting.The BNO08X datasheet says SH-2 algorithms apply bandwidth-limiting filtering and therefore add delay. The public SH-2 driver also contains a
sensorSpecificword in Set Feature, but DepthAI does not expose it and we could not find documentation showing that it controls raw accelerometer/gyroscope bandwidth.Move to the what
Could Luxonis clarify the exact behavior of
ACCELEROMETER_RAWandGYROSCOPE_RAWon BNO086 firmware 3.9.9?sensorSpecificSet Feature word support bandwidth selection for these raw reports on BNO086?Move to the how
If BNO086 firmware supports a safe bandwidth selection, please expose it as explicit optional fields in
IMUSensorConfig, with per-IMU validation and readback of the effective configuration. It would also be useful to document whether changingreportRatechanges only the report interval or also changes the physical sensor ODR/filter configuration.We are not requesting raw register access or an undocumented firmware workaround. A fail-closed, vendor-supported API plus documented delay/frequency response is required before this could be used in a VIO production path.