FixTheRobot Explore Robotics / Systems Engineering / Troubleshooting

Troubleshooting · SLAM and localization

GNSS-to-indoor transition causes a pose jump

The pose steps by metres as the robot enters the building. The step is a correction that was applied all at once; find which source disagreed with which and why.

  • Related modules: 12
  • ROS 2 Jazzy

1. Symptoms

  • The published pose, or the robot’s position on the map, steps by a metre or more near the building entrance.
  • The jump happens at the same place every run.
  • Planners re-plan or controllers lurch at that moment.
  • After the jump the map frame is consistent indoors but off relative to the outdoor map.

2. Possible causes

  • Map misalignment: the indoor map is registered with an error relative to the GNSS frame, and the estimator moves from one frame to the other.
  • Silently biased GNSS near the building: multipath error with a small reported covariance; when GNSS drops the correction disappears.
  • Hard switch between two independent estimators instead of one estimator with changing weights.
  • Overconfident indoor localiser: it takes over with a covariance that is too small, so the filter jumps to it.
  • Frame or datum error in the GNSS-to-local conversion.
  • Unmodelled odometry drift outdoors that GNSS was hiding.

3. Measurements to collect

  • The published pose, the GNSS position, the indoor localiser pose and the odometry, all in one frame, over the transition (record a bag).
  • The size and direction of the jump and the position where it occurs.
  • The reported covariance of each source around the jump.
  • GNSS health indicators (fix status, covariance, innovation against odometry) in the minutes before it.
  • The registration offset between the indoor map and the GNSS frame, if it can be measured at surveyed points.

4. Diagnostic commands

Commands are not executed by the site’s automated tests (they need a ROS 2 Jazzy installation or the robot).

ros2 bag record -o transition /fix /odometry/filtered /tf /tf_static   # add your indoor localiser's pose topic
ros2 topic echo /odometry/filtered --field pose.covariance --once
ros2 run tf2_ros tf2_echo map odom                                     # does map->odom step at the entrance?
ros2 run tf2_tools view_frames

5. Step-by-step investigation

  1. Locate and size the jump on the recorded data. If map → odom steps while odom → base_link stays smooth, the correction is applied at the map level (the expected place).
  2. Compare sources in one frame before and after the jump. The difference between the GNSS-based and the indoor-localiser positions around the entrance is the size of the inconsistency.
  3. Decide which source is wrong. If GNSS was already drifting away from odometry before the jump, it was biased (see the GNSS-degradation guide). If the sources agree outdoors in the overlap and differ by a constant, the map registration is off.
  4. Check the covariances at the switch. If the indoor localiser claims much higher confidence than GNSS at that moment, the estimator will follow it immediately.
  5. Try the handover model. Reproduce your numbers in the Localization Handover Visualizer to see which mechanism gives a jump of that size.

6. Corrective actions

  • Estimate the map-to-GNSS alignment during the overlap, while GNSS is healthy, and apply it to the indoor localiser’s output.
  • Gate GNSS with an innovation test and hysteresis so a biased fix is not absorbed before the transition.
  • Use one estimator with covariance-weighted inputs rather than switching between two estimators.
  • Set realistic covariances on the indoor localiser during its convergence period.
  • Limit the rate at which the published pose may absorb a correction (slew limit) and let planners handle the correction explicitly; this hides the jump, it does not remove the inconsistency.
  • Re-register the indoor map against surveyed points.

7. Validation after the fix

  • Drive the transition at least 20 times in both directions: the largest pose step stays below your limit every time.
  • The pose error against a surveyed reference through the doorway stays within the allowed bound.
  • The alignment estimate converges to the same value on repeated runs.
  • Deliberately degrade GNSS (drive closer to the wall): the transition stays smooth.

References

  • See the guide on detecting GNSS degradation and the Module 12 overview for the architecture.