A smooth fused trajectory and a small reported covariance do not prove that a robot’s measurements are independent. Wheel odometry may publish position, heading and velocity derived from the same encoders. Another estimator may already contain those encoder observations. Feeding both outputs into a downstream filter can count related information more than once.
Before changing covariance, draw the measurement provenance: which physical observations contribute to every selected input variable? The useful audit follows data ancestry across topics and estimators, rather than counting topic names. Apparent overconfidence can have other causes, so duplicate inputs should remain a hypothesis until the configuration and a controlled comparison support it.
This workflow is for a LiDAR robot using robot_localization or a comparable fusion pipeline. It does not provide a universal sensor-selection recipe or a numerical confidence test. Pin the deployed package version, driver settings and upstream estimator configuration. Development documentation cited here is a reference to verify against that installed system.
Draw ancestry before choosing input variables
Begin with the sensors, not the ROS graph. Draw wheel encoders, IMU, LiDAR and any other physical observations as separate origins. Then add drivers, scan matching, visual or inertial odometry, local filters and the final consumer. Mark every point where one estimator consumes another estimate. Two independently named topics can still descend from the same observation.
A controller’s odometry message may contain integrated position and instantaneous velocity from the same encoder stream. A LiDAR–inertial odometry output may contain IMU information that is also sent directly to another filter. These are illustrative dependency patterns, not claims about every implementation. Read the actual upstream configuration and documentation before deciding that an input is independent.
The robot_localization configuration tutorial explicitly discusses duplicate information in wheel-derived pose, heading and velocity. Its example motivates tracing provenance; it is not a configuration to copy unchanged into a different robot. Record the reason each selected variable supplies useful information and identify any shared source.
Separate pose, twist and their frame meanings
The Odometry message contract assigns pose to header.frame_id and twist to child_frame_id. Read those fields in the recorded messages. Plotting quantities with similar names on the same axes does not make their origins or coordinate frames equivalent.
For each input, list position, orientation, linear velocity and angular velocity separately. Add the native sensor, processing method, timestamp meaning and covariance origin for each group. Include whether pose was integrated from the same twist, whether yaw came from an IMU and whether an upstream filter already fused another input. Leave undocumented ancestry unknown rather than assuming independence.
Frame semantics also affect interpretation of disagreement. The REP 105 frame definitions distinguish continuous local odometry from a global map frame that can jump. A reset or global correction is not automatically evidence of duplicate fusion. The TF diagnostic workflow can help isolate a separate frame or timing problem before a provenance experiment.
Read the effective selection vectors
Export the parameters actually loaded by the running node, including launch overrides and input remapping. A reviewed YAML file is insufficient if another launch layer changes it. Match each input index to the topic that reaches that subscription and annotate the selection vector with variable names. Keep disabled fields visible in the worksheet so their omission is deliberate.
The state-estimation reference specifies the ordered per-input variable selection and explains differential and relative processing. Those operations alter how pose is used; they do not create a new physical observation or establish independence from another input. Check their version-specific behavior before interpreting a change as a correlation remedy.
The data-preparation guide recommends explicit variable selection instead of inflating covariance to make an unwanted variable effectively disappear. Keep selection and uncertainty as separate decisions. A covariance value should describe its documented uncertainty basis, not serve as a hidden switch that conceals an unexplained dependency.
Also check feedback: does an upstream producer consume the final filter output, directly or through a republisher, and then feed a derived result back as another input? Document every dependency. The broad robot sensor-fusion overview helps inventory components, while this audit asks the narrower question of which observations each component already contains.
Build a variable-level provenance worksheet
| Input group | Provenance question | Evidence needed |
|---|---|---|
| Wheel-derived pose and twist | Are both generated from the same encoder samples? | Controller implementation and integration settings |
| IMU orientation and wheel yaw | Does wheel yaw already incorporate that IMU? | Controller fusion configuration |
| LiDAR odometry and raw IMU | Which IMU observations already enter the odometry? | Odometry pipeline and calibration configuration |
| Two filtered outputs | Do they share observations or consume each other? | Both input lists and data-flow directions |
| Republished measurement | Is it genuinely new evidence or a renamed copy? | Republisher transformation and timestamp policy |
Use this sheet to identify one specific overlapping path to investigate. Do not remove all secondary inputs at once. Some measurements may contribute useful constraints despite sharing part of their ancestry, but accounting for that relationship requires an estimator design that supports the intended use. If cross-input correlation is material, establish how the chosen implementation handles it rather than assuming topic-level covariance fields solve the problem.
Separate the provenance question from the quality of the upstream estimate. A LiDAR–inertial system may work well on its own and still share information with another input. The LiDAR–inertial odometry explanation provides context for identifying that dependency without assigning blame to either sensor.
Compare one justified input change at a time
Keep a baseline recording with the raw inputs, effective parameters, diagnostics and an appropriate independent reference where available. Define the candidate configuration from the provenance sheet. Change only the identified overlapping variable group, keeping initial conditions, frame transforms, replay timing and other input selections consistent.
Compare estimated motion, reported uncertainty, discontinuities and differences from the reference over the same intervals. Include stationary periods and representative movement supported by the platform’s test procedure. A larger covariance after removing an input can be more honest without proving better accuracy; a smoother path can also conceal a lost constraint. Judge both behavior and the evidence supporting uncertainty.
Do not invent a covariance to force the expected result or select a threshold after viewing the trial. Record uncertainty provenance and known limitations. Preserve the original data as described in the sensor recording workflow, so another reviewer can reproduce the comparison rather than relying on a screenshot of the final trajectory.
Questions that arise during the audit
Are two odometry topics always duplicates?
No. Their physical sources and processing determine the relationship. Conversely, one message can contain several fields derived from a single source. Audit at variable level rather than deciding from message count.
Does differential mode remove correlation?
It changes the treatment of a pose input. It does not establish independent ancestry. Confirm what information remains shared and whether the selected estimator design can use it appropriately.
What should be retained for engineering review?
Keep the dependency drawing, variable worksheet, loaded configuration, exact revisions and baseline/candidate comparison. Use the reproducible support bundle guide to package them. The conclusion should identify the supported input decision and its limitations, rather than equating a small covariance with a trustworthy robot pose.
