When LiDAR–IMU fusion turns much farther or less far than an independently observed rotation, verify angular-velocity units before tuning the filter. Trace the native gyro representation through the driver and every conversion wrapper to the published ROS message. A field named angular_velocity does not prove that its numbers satisfy the message contract.
Separate scale, axis direction, clock interpretation and mounting orientation. A unit conversion changes numerical scale; it does not establish correct axes or a valid time interval. Correcting one boundary can leave another error untouched. Preserve original device output and published samples so that each change can be checked against the same observation rather than a different movement.
The gravity-removal diagnostic owns a different IMU boundary: linear acceleration and gravity handling. This article examines rotational velocity and its uncertainty. It does not claim that a particular sensor uses degrees, provide a universal calibration maneuver, or assume that a smooth fused path demonstrates correct numerical units.
Write both sides of the unit contract
The REP 103 conventions establish the ROS unit framework. Begin the integration record with the manufacturer’s exact native-output specification and the units expected by the receiving ROS interface. If the native document is unavailable or ambiguous, record that gap. Do not infer units solely from the numerical magnitude seen while a sensor is stationary.
Inspect firmware modes and driver settings that may change the native representation. A raw integer count, a value already converted by a device library and a physical angular rate are different boundaries. Name each one in order. Include the numerical type and any scale coefficient with its source, rather than embedding an unexplained multiplier in a launch argument.
The support bundle checklist helps preserve the exact device and software context. Keep the original native sample and the corresponding published ROS sample together. Another engineer should be able to identify where units first became physical and where they changed again without needing an entire robot deployment.
| Boundary | Record | Typical confusion |
|---|---|---|
| Native gyro output | Specified representation and coefficient | Counts assumed to be physical units |
| Driver conversion | One identified conversion stage | Degrees-to-radians applied twice |
| ROS field | Actual angular_velocity samples | Quaternion validity assumed to certify rate |
| Covariance | Matching squared units | Variance scaled like standard deviation |
| Timing | Acquisition intervals and clock meaning | Configured rate substituted for elapsed time |
Check angular_velocity separately from orientation and acceleration
The Jazzy Imu definition explicitly specifies rotational velocity in rad/sec and linear acceleration in m/s². It also carries orientation and separate covariance arrays. Inspect the particular field being converted. A correct orientation quaternion does not prove correct angular velocity, and a correct acceleration scale does not certify the rotational channels.
If the documented native angular rate is in degrees per second, the scale conversion to radians per second uses pi divided by 180. Apply that conversion at one identified boundary. If the native library already returns radians per second, applying the same conversion again introduces an error instead of repairing one. Preserve the preconversion value in the diagnostic record.
The IMU covariance contract explains availability and uncertainty fields. Do not replace their documented sentinel meaning while fixing a scale issue. In particular, numerical conversion of an angular rate is distinct from declaring an unavailable orientation estimate valid or assigning invented certainty to a measurement.
Keep the uncertainty in the same units as the value
The REP 145 IMU reporting guidance provides context for sensor and world-frame conventions. Preserve those conventions while examining uncertainty. For a vector multiplied by one scalar factor a, its covariance matrix transforms by a squared. That mathematical relationship follows from covariance scaling; it is not a performance specification for an IMU.
For a conversion applied uniformly to all angular-velocity components, keep the angular-velocity covariance in the resulting squared units. Do not multiply a covariance by a as though it were a standard deviation. Also do not rescale orientation covariance or acceleration covariance merely because another field in the same message required conversion. Each array describes a different quantity.
An axis transformation is a separate operation. A full covariance matrix under a coordinate rotation must follow the appropriate matrix transformation, rather than a simple unit-scale shortcut. Check which conversion the driver already performs before adding another one. Preserve off-diagonal terms when they carry supported information; silently dropping them can change the uncertainty model.
Compare a known rotation with identified timestamps
The Jazzy Vector3 definition identifies the three-component representation used by angular velocity. Read those components in their documented sensor frame. A vector’s numbers need a frame convention and units before they describe a meaningful rotation rate. An apparent sign problem may belong to the selected axis or transform rather than the scale factor.
Use a suitable controlled sensor or robot test in which an independent angular reference and the relevant time interval are known. Preserve the original rate samples and acquisition timestamps. Compare the integrated interpretation with the reference without reporting a guessed accuracy figure. Keep positive and negative rotations distinct so that an axis-sign problem is not mistaken for a scale correction.
The timestamp-unit workflow addresses the time side of the calculation. Correct rate units combined with an incorrect time scale can still produce a wrong angle. Do not use recorder arrival time as acquisition time without documenting that substitution, and do not assume a nominal configured frequency equals every observed sample interval.
Return to fusion only after the producer boundary is understood
The reviewed ROS 2 fusion implementation is useful for checking a specific downstream preparation or transform question. Pin the installed package revision and trace the actual subscribed field. A downstream estimator cannot be assumed to recognize an undocumented unit convention just because the message type and topic names are accepted.
Repeat the same bounded capture after one deliberate conversion change. Compare published angular rates and uncertainty before evaluating the fused trajectory. Keep configuration, sample timing and initialization conditions consistent. A different result after a different physical movement is insufficient to establish that the conversion was corrected, especially when several sensors constrain the same orientation state.
Use the heading reference diagnostic if a residual geographic rotation remains after scale and timing are established. Heading origin, north convention, mounting orientation and gyro rate units are related integration concerns, but they are not interchangeable fixes. Record which one the evidence actually supports before changing another parameter.
Frequently asked questions
Does ROS angular_velocity use degrees per second?
The reviewed Imu message specifies rad/sec. The native device interface may use another representation, so verify its documentation and trace where the driver performs conversion. Do not assume that raw device values already match ROS units.
Can a covariance change fix a wrong gyro scale?
Changing uncertainty does not correct the numerical unit contract. Establish the value’s scale first, then preserve uncertainty in matching units. Tuning can alter how an estimator responds while leaving the underlying measurement error present.
Should I scale every covariance in the Imu message together?
No. Orientation, angular velocity and linear acceleration are distinct quantities with separate covariance arrays. Apply only the transformations justified for each field, preserving availability conventions and supported coordinate transformations.
Why can the fused path look plausible despite incorrect rate units?
Other observations or estimator behavior can obscure an incorrect producer field. Validate the published rate against an independent bounded observation before treating a visually smooth trajectory as evidence of correct units.
