An all-zero IMU covariance and a minus-one first covariance element mean different things in the ROS message contract. Zero covariance indicates that uncertainty is unknown. A first element of minus one marks the associated estimate as unavailable. Neither should be interpreted as a measurement known to be perfect.
Before fusing an IMU, define a contract for each of its three data groups: orientation, angular velocity and linear acceleration. Record whether the group exists, its units and frame, where its uncertainty came from, and how the deployed consumer handles unknown or absent data. The message and the filter configuration need to tell a consistent story.
This is an interface and uncertainty-provenance audit, rather than a gravity-removal or sensor-calibration procedure. Development source and documentation below illustrate what to inspect. Confirm the actual driver and consumer revisions on the robot; a historical issue report cannot establish current behavior for a different installation.
Read the three covariance blocks separately
The Imu message definition supplies separate row-major covariance arrays for orientation, angular velocity and acceleration. It defines all zeros as unknown covariance and minus one in the first element as no estimate for that group. A consumer should disregard the associated unavailable estimate. The validity of one group does not establish the validity of the other two.
Inspect recorded values from startup and normal operation. Check the actual arrays, not only the driver’s parameter file or a visualizer label. A device that reports gyroscope and accelerometer data may lack an orientation estimate, while a processing node can add one later. Keep the distinction visible when the topic moves through republishers or format converters.
Do not confuse the orientation covariance’s three axes with the quaternion’s four components. Nor should a valid-looking quaternion alone override an explicit unavailable marker. The message describes both a value and its interpretation. A consumer that ignores part of that contract needs a documented compatibility decision rather than an unexplained producer-side workaround.
Trace units, frames and uncertainty provenance
Use the REP 103 units and coordinate conventions as the shared reference for angular and linear quantities. Document the corresponding squared units in each covariance block. A standard deviation and a variance are different quantities; copying a manufacturer’s noise figure directly into a variance field can be wrong even when the number appears plausible.
Ask what the uncertainty represents. Was it reported by firmware, supplied from a documented characterization, configured from an engineering model or copied from a sample file? Preserve the operating conditions and limitations. A number estimated for one output mode or bandwidth is not automatically applicable after filtering or changing the sensor configuration.
The draft REP 145 driver-convention proposal distinguishes raw and orientation-bearing IMU outputs and discusses covariance overrides. Treat it as a convention reference, not certification of a particular driver. Inspect any override parameters actually loaded by the node and retain the original firmware-reported values when available.
Frame conversion can change the matrix as well as the vector. Verify the driver or republisher’s documented transformation of both. Record the sensor mounting reference and timestamp policy. The sensor calibration workflow helps organize installation evidence, while the clock-check guide addresses whether the value and its orientation belong to the same epoch.
Compare the producer contract with the consumer
Read the deployed consumer’s message-validation path and variable-selection settings. Distinguish not selecting orientation for direct fusion from telling the consumer that no orientation estimate exists. Preprocessing can still depend on attitude even when orientation is not selected as an output-state measurement.
In the inspected robot_localization development implementation, the IMU callback checks the unavailable marker independently for orientation, angular velocity and acceleration. Its acceleration preparation also distinguishes message orientation from a state-orientation fallback for gravity removal. Inspect these paths in the installed revision before expecting a configuration change and a validity-marker change to behave identically.
The data-preparation documentation warns against leaving zero variance for selected variables and against using inflated covariance as a substitute for deselection. A numerical fallback inside a consumer does not turn unknown uncertainty into a defensible sensor model. Document any assumed covariance explicitly and establish its engineering basis.
If acceleration preprocessing is the suspected problem, use the separate stationary-robot gravity-removal diagnostic. Changing an unavailable-orientation marker can affect that path, but it does not by itself prove that gravity is being removed twice. Keep message validity and preprocessing as related, separately testable questions.
Build a contract worksheet before integration
| Data group | Producer statement | Consumer evidence |
|---|---|---|
| Orientation | Present or absent; world reference; quaternion validity | Marker handling, direct selection and preprocessing use |
| Angular velocity | Units, sensor axes and covariance origin | Selected axes, transforms and invalid-data path |
| Linear acceleration | Units, gravity content and uncertainty basis | Validity gate, selected axes and gravity treatment |
| All covariance blocks | Unknown, supplied or configured; squared units | Fallbacks, overrides and matrix transformation |
| Timing | Measurement time, publication time and startup behavior | Freshness and transform availability at measurement time |
Assign an owner to every unresolved field. For example, a driver maintainer can establish whether firmware supplies covariance, while the integration team defines whether an application may run with an explicit assumed uncertainty. Preserve unknowns until evidence resolves them. Filling a worksheet with copied defaults only hides the uncertainty that the contract was intended to expose.
Test startup, unavailable groups and missing data
Use controlled saved messages or a test harness to check the documented contract before relying on it during motion. Include orientation absent with angular velocity and acceleration present, an all-zero covariance block, a valid supplied covariance, and a gap in the stream. Malformed numerical data is another case to handle; it should not be equated with a valid unknown-covariance marker.
Observe which measurement groups enter the filter, which are rejected and which assumptions are applied. Keep the loaded parameters and diagnostics beside each input case. Test direct selection and message validity separately so an effect on gravity preprocessing is not mistaken for an effect on direct orientation fusion. Do not run fault-injection cases on an uncontrolled moving platform.
Compare behavior against the declared contract, not merely whether the node stays alive. A continuously published pose can conceal an ignored measurement or an undocumented uncertainty fallback. The robot sensor-fusion overview helps identify other inputs that may keep an estimate active while the IMU group is absent.
Check transitions as well as isolated examples. When an orientation-producing node starts late or restarts, verify that the availability marker changes with the estimate it describes and that an old quaternion is not silently presented as current. Preserve the producer timestamp and the consumer decision for each case. A contract that works only after a favorable startup sequence is incomplete, even if ordinary operation looks stable.
Frequently asked questions
Does zero covariance mean exact measurement?
No. In this message contract, an all-zero block means covariance is unknown. Establish a documented uncertainty basis before using the group where the consumer requires one.
Can a large covariance replace the absent-data marker?
They express different intentions. An absent estimate should be marked as such; a deliberately unselected variable belongs in the consumer configuration. Do not rely on an arbitrary large number to encode either meaning.
What evidence should accompany a driver review?
Provide representative messages, the per-group worksheet, driver and consumer versions, active overrides and controlled-case results. Follow the reproducible support bundle guide. A completed contract explains which data exist, what their uncertainty means and how missing evidence affects the actual consumer.
