If global position corrections appear as sudden movement in a LiDAR robot’s local odometry, inspect the filter’s world_frame and transform responsibilities before tuning covariances. First decide which output must remain locally continuous and which output may incorporate discontinuous global corrections. Those are different contracts, even when both outputs describe the same physical robot.
A global correction is not necessarily a sensor failure. A globally referenced estimate may change when new absolute information becomes available. The integration problem arises when a consumer expecting locally continuous motion receives that correction in the wrong representation, or when the transform tree does not separate local motion from the global reference as intended.
Use the GNSS heading diagnostic when the disagreement is a rotated geographic track. This article owns another boundary: the continuity and frame contract of local and global estimates. It does not treat changing a frame name as a coordinate transformation or assume that adding a second filter automatically establishes a correct architecture.
Define continuity before drawing the transform tree
The REP 105 frame conventions distinguish the locally continuous odom frame from a map reference that can change discontinuously. Write down which consumers require each property. A controller tracking short local motion and an application locating the robot in a global map may legitimately consume different representations of the same trajectory.
Record what is actually observed during a correction: a map-to-odom change, an odom-to-base change, an Odometry pose change or only a visualization jump. Save timestamps and frame names with those observations. Several screen traces can move together because of the display’s fixed frame, so appearance alone does not identify which transform or message changed.
The TF timing workflow helps when observations are made at incompatible times. Establish time alignment before calling a transform discontinuous. A delayed transform lookup and an actual global correction can produce different failures, and neither should be hidden by relabeling old measurements with current timestamps.
| Component | Contract to record | Evidence |
|---|---|---|
| Continuous local output | Expected local continuity | Pose and transform samples around correction |
| Global estimate | Absolute reference and permitted correction | Source measurement and world frame |
| Transform edge | One intended publisher and meaning | Live publisher ownership |
| Odometry message | Pose frame and twist child frame | Actual message fields |
| Consumer | Which continuity property it expects | Resolved input and effective configuration |
Map each measurement to its actual filter instance
The reviewed ROS 2 robot_localization parameter example describes world_frame choices and the distinction between continuous inputs and global position updates. Pin the installed package version and inspect its effective values. The upstream ros2 branch reviewed for this diagnostic is a source reference, not a guarantee that every released binary has identical defaults.
Inventory every input by physical origin, measured variables and reference frame. Distinguish locally continuous wheel, visual or inertial information from an absolute update that can introduce a correction. Do not classify an input solely by its topic name. A message called local_odometry may already contain a global correction from an upstream estimator.
The duplicate-input audit establishes whether apparently separate streams reuse the same underlying observation. Keep that evidence separate from the world-frame decision. Changing world_frame or launching another estimator does not make correlated inputs independent, and covariance tuning cannot substitute for knowing where each measurement originated.
Assign transform responsibilities explicitly
The reviewed ROS 2 state-estimation documentation explains the expected frame relationships. When using a map-referenced global estimate, verify the corresponding continuous odom-to-base relationship and who supplies it. Inspect the deployed implementation rather than copying ROS 1 launch syntax or assuming that the documentation’s example matches a namespaced robot.
Write a small responsibility table listing each transform edge, its publisher and its intended continuity property. Distinguish configuration frame names from the numerical transformation applied to measurements. A changed string does not rotate, translate or otherwise convert a pose. Confirm both the frame identifiers and the actual values at the boundary where another consumer reads them.
Use the TF ownership diagnostic to exclude duplicate broadcasters and colliding robot IDs. This is a separate prerequisite: even a well-designed local/global split can fail when two nodes publish the same edge. Preserve evidence of the active publishers before changing any filter configuration.
Read the output message with its frame contract
The Jazzy Odometry definition specifies the reference frame of pose and the child frame associated with twist. Capture these fields with the numerical output and covariance. Do not assume that pose and velocity are expressed in the same frame merely because they arrive in one message.
Compare the local and global outputs around one identifiable correction event. Record the original inputs so that another engineer can reproduce the comparison. A useful result separates ordinary local motion, the global reference change and any unexpected jump in a supposedly continuous output. Avoid using only a path plot that has already transformed both streams into one changing display frame.
Check the configuration actually loaded by each filter with the effective YAML parameter workflow. Two instances can accidentally load the same input list or world_frame after a namespace change. Preserve effective values from both nodes; a pair of different launch filenames does not establish that the running instances behave differently.
Replay a correction without hiding its timing or magnitude
Use the reviewed ROS 2 filter implementation to investigate an unresolved output boundary in the installed version. Source inspection should answer a specific question, such as which output transform is published under the selected world frame. Do not infer all runtime behavior from a parameter comment when a local patch may change the code.
Include a bounded interval without the absolute update and a later interval when it becomes available again. Keep the locally continuous input unchanged between comparisons. Record whether the observed correction occurs in the global reference, the local output or both. Do not compare independent runs with different initialization poses and label the resulting offset a global correction; preserve the starting conditions and the exact event that supplied new information.
Repeat the same bounded input with one intentional configuration change. Include initialization and restart observations separately from steady operation. Record whether the supposedly continuous output remains continuous through the global correction, and whether the global representation still incorporates the intended absolute information. A smooth trace obtained by suppressing useful input is not automatically a correct fusion result.
Prepare a reproducible fusion support record with both filter configurations, input provenance, transform publishers and the correction timeline. State which continuity requirement failed and where. This gives another engineer a concrete architecture question to resolve, instead of a vague report that the robot jumped after GPS improved.
Frequently asked questions
Does a global map correction always indicate a bad estimate?
No. A globally referenced estimate can legitimately incorporate a discontinuous correction. Diagnose whether the correction enters a representation or consumer that requires local continuity, and verify the associated transform responsibilities.
Can changing frame_id make a global pose into local odometry?
No. A frame identifier describes a coordinate contract; changing the string does not perform the numerical transformation or create continuity. Inspect the actual transforms, measurement origins and consumer expectations.
Are two filter instances always required?
Do not apply a universal architecture rule. Follow the deployed package’s supported frame contract and the application’s inputs and consumers. Whatever arrangement is selected, verify continuous local motion, global correction behavior and unique transform ownership explicitly.
