GPS position jumps

1. Symptoms

• Latitude and longitude move by metres while stationary.
• The jump coincides with entering shade, passing a building or losing a correction link.
• The map pose jumps and the robot swerves.

2. Possible causes

• Multipath near buildings, vehicles or water.
• Loss or change of RTK fix status (for example fixed to float to a plain fix).
• Poor satellite geometry or few satellites under trees.
• Antenna or cable fault or interference from onboard electronics.
• Frame errors: mixing the antenna frame and the robot frame, or a datum or ENU conversion issue.
• Fusion: a filter that trusts GNSS too much with a wrongly small covariance.

3. Measurements to collect

• NavSatFix status, covariance and its covariance type, logged with the position.
• Number of satellites and the correction age from the receiver’s own messages.
• A recording of position while stationary in open sky and in the problem area.
• The covariance the filter used.

4. Diagnostic commands

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

ros2 topic echo /fix --field status
ros2 topic echo /fix --field position_covariance
ros2 bag record /fix /gps/extra

5. Step-by-step investigation

1. Plot position against time with the status and covariance; mark every jump.
2. Check the status: NavSatStatus −1 is no fix, 0 a plain fix, 1 SBAS, 2 GBAS; a fix is valid when status ≥ 0. Read the receiver’s RTK status if it publishes one.
3. Check the covariance: it should grow when quality falls; a constant small value means the driver is not reporting real quality.
4. Compare with the environment: open sky vs near structures.
5. Check the antenna and cable; move electronics away; try another position.
6. Check the fusion: reject or inflate GNSS on a jump (see the GNSS degradation guide).

6. Corrective actions

• Place the antenna with a clear sky view and away from noise sources.
• Use RTK with a reliable correction link and monitor the fix status.
• Make the driver publish a realistic covariance and use it in the filter.
• Gate measurements with a Mahalanobis test and slow the correction on jumps.
• Fuse with IMU and odometry so a short GNSS error is not followed.

7. Validation after the fix

• No jumps larger than the requirement in the whole operating area.
• Status and covariance track the visible quality.
• The robot pose stays smooth across a deliberately degraded GNSS section.

References

• sensor_msgs definitions (Jazzy): ros2/common_interfaces, read 2026-11-05. NavSatFix and NavSatStatus.
• Related guide: GNSS degradation guide.