If a stationary robot appears to accelerate in its localization filter, inspect the acceleration convention before adjusting noise. A resting accelerometer can legitimately report a gravity-related specific-force vector. A processed acceleration topic may already have that contribution removed. Applying the same removal again, or using the wrong orientation to remove it, can create a false acceleration.
Start by identifying the exact topic being fused, its physical sensor frame and every processing stage between the device and the estimator. Then compare a retained stationary recording with the effective gravity-removal setting. The goal is one documented conversion where needed, rather than toggling settings until a position plot looks quiet.
This diagnostic concerns acceleration preprocessing in a ground-robot state estimator. It is separate from LiDAR–IMU initialization motion and does not establish sensor accuracy. Keep the receiver or IMU firmware, driver settings, ROS distribution and localization package revision with the evidence. Development references below must be checked against the installed release.
Read the stationary vector before interpreting the estimate
Record all three acceleration components, not just their magnitude or one selected axis. The ROS Imu message requires acceleration in meters per second squared and angular velocity in radians per second. Confirm whether the device uses these units natively or the driver converts them. A value expressed in g cannot be treated as an SI acceleration without conversion.
The draft driver-convention proposal REP 145 describes accelerometer output as specific force: at rest with the sensor z axis upward, that axis reports positive g. This is a useful reference convention, not proof of what a particular processed topic contains. Check the manufacturer’s manual and the actual driver’s processing path.
Observe the sensor in a known stationary orientation, with the robot secured according to its test procedure. If permitted, compare another supported orientation using a bench fixture rather than tipping a powered vehicle. Note which components change and whether the vector follows the expected sensor axes. The REP 103 coordinate conventions provide the common right-handed body-axis reference. Keep each observation tied to its physical orientation.
Locate the stage that changes gravity content
Draw the path from the physical sensor through firmware, driver, orientation estimator, republisher and localization input. For every stage, write whether it changes units, rotates axes, estimates attitude, removes gravity or changes covariance. Preserve the original topic if it is available. A name such as filtered or corrected does not specify which operations occurred.
Compare corresponding samples before and after each stage using measurement timestamps. Look for a documented change in the stationary vector, rather than inferring processing from the final magnitude alone. Filtering, bias, orientation and vibration can also affect the vector. The sensor clock-check workflow helps prevent a time mismatch from being mistaken for a preprocessing difference.
Keep calibration distinct from this contract audit. A driver may publish a valid but differently defined output; a stationary residual may also contain bias. The LiDAR–IMU excitation diagnostic addresses whether initialization motion is sufficient. It does not determine whether a downstream acceleration topic has already had gravity removed.
Check orientation and the installed transform together
Gravity removal depends on orientation, not only a scalar subtraction from z. On a tilted sensor, the gravity-related vector projects across axes. Inspect the quaternion’s validity, world-reference convention, timestamp and the rigid mounting transform. A sensor-frame rotation and an earth-reference convention are different relationships; changing one does not automatically repair the other.
The robot_localization data-preparation guide discusses expected frame conventions and the sensor mounting transform. Compare the installed transform with physical measurements. Check that the transform is available for the message time and that there is a single intended authority. Use the separate TF time-coverage procedure when lookups fail.
Do not supply an identity quaternion merely to satisfy an interface when orientation is unavailable. That value asserts a particular attitude. Also distinguish an orientation excluded from direct fusion from an orientation that preprocessing may still use. Inspect the deployed consumer’s handling rather than assuming that disabling roll, pitch and yaw fusion prevents every use of the quaternion.
Inspect the actual gravity-removal branch
The state-estimation parameter reference documents imuN_remove_gravitational_acceleration and the gravity magnitude parameter. It describes using message orientation when available and state orientation when the message marks orientation absent. Save the effective parameter values, including the correct input index. A setting for imu0 does not describe another configured IMU input.
In the inspected development implementation, acceleration preparation transforms the measurement, constructs the gravity-related vector using the relevant orientation path and subtracts it when enabled. Its behavior depends on message validity and configuration. Historical issue reports are useful questions to investigate, but do not establish that an old transformation-order problem exists in the installed release.
For a saved stationary run, compare the original configuration with a single justified preprocessing change. Keep other inputs, initial state, replay timing and mount transform unchanged. Record the acceleration entering fusion as well as the resulting velocity and pose. A planar constraint can conceal a vertical symptom, so inspect the selected variables and intermediate data instead of relying only on a flat trajectory.
Keep three evidence layers separate during this comparison: the incoming message, the acceleration after preprocessing, and the filter state. The published state is influenced by other sensors and the prediction model, so it cannot reveal the preprocessing operation by itself. If the deployed package exposes suitable diagnostics, record them; otherwise inspect the relevant calculation in a controlled development replay. Preserve the exact input file and configuration for that replay. Annotate any omitted measurements or unavailable intermediate values rather than presenting an inferred residual as directly observed. This separation makes it possible to explain why a change helped without claiming that the whole localization system has been validated.
Choose the next check from the evidence
| Observation | Question | Evidence to retain |
|---|---|---|
| Stationary vector follows the sensor axes | Does it match the documented specific-force convention? | Raw vector, units and physical orientation |
| Processed vector is already gravity-compensated | Is the estimator repeating that operation? | Upstream processing settings and input topic |
| Residual changes with tilt | Are attitude and mounting conventions consistent? | Quaternion, reference convention and measured transform |
| Orientation is unavailable | Which fallback does this consumer release use? | Validity marker, installed source and initial state |
| Filter moves despite plausible input | Are bias, timing or other fused inputs responsible? | Complete input recording and diagnostics |
Define a residual criterion from the application and reference uncertainty before judging a replay. Do not copy a universal threshold from an example or change covariance to conceal an unexplained acceleration. A quieter estimate is useful only when the input convention and the operation that changed are known. The robot sensor-fusion overview helps place this narrow check within the larger input pipeline.
Questions during integration
Should stationary acceleration always be zero?
No. That depends on whether the topic reports accelerometer specific force or a processed gravity-compensated quantity. Document the topic’s meaning before setting an expectation.
Can gravity removal fix accelerometer bias?
It addresses a different contribution. An unexplained residual still needs investigation of bias, orientation, timing and mounting. Do not treat a preprocessing switch as a complete calibration procedure.
What should a review bundle contain?
Include a brief stationary recording, physical orientation notes, raw and processed topics, effective parameters and exact software versions. Follow the reproducible support bundle guide. A useful conclusion identifies where gravity content changed and shows a controlled comparison, rather than only a smoother final path.
