Declination usage in navsat_transform

Question

I am running the navsat_transform node using a set datum point to get (x,y) coordinates in the map frame.

I am inputting the same GPS lat/long values, just changing the declination. Using 0.0 for the declination value, the points output are represented by the Orange line in the photo. Using 0.1209513 for declination, the points output are represented by the Pinkline.

The top portion of the Blue line is the robot travelling the path using the points output using 0.0 for declination.

The desired real-world line should be the Orange line. We are using RTK GPS to gather points and in the navigation of the robot. Our IMU data is corrected for declination already.

I have looked through robot_localization source and understand the point is being rotated about the datum.

How is the declination parameter to be used? It seems adding the correct declination in the navsat_transform_node paramater places the map points in the incorrect place. We were considering removing the declination correction from our IMU driver and using the navsat_transform param.

The params used (this node is running by itself, off bot just to test differences in using the declination parameter; similar on real bot):

 navsat_transform:
      frequency: 5
      delay: 3.0
      magnetic_declination_radians: 0.0 #0.1209513
      yaw_offset: 0.0
      zero_altitude: true
      broadcast_utm_transform: true
      publish_filtered_gps: true
      use_odometry_yaw: false
      wait_for_datum: true
      datum: [38.038643, -103.694626, 0.0]

---

Originally posted by hapy-capy on ROS Answers with karma: 33 on 2022-12-15

Post score: 1

Answer 1

The Blue line plotting /odometry/global (output from our global EKF node) shows the behavior when this erroneous point rotation was used in the original version of this PR.

The Orange line is plotted between two waypoints correctly by Robot Localization (through the /fromLL service). The erroneous point rotation mentioned caused the planned waypoint path (Blue Line) to be rotated again by the utm_meridian_convergence value calculated and used by the Navsat Transform Node (RL does this internally but here is an example of how it's calculated). The /fromLL service already deals with this when transforming Lat/Long->Map (x,y), so the rotation was basically being "doubled" (this discussion sheds light). RL also accounts for things like a user set yaw_offset, magnetic_declination, etc., that would have also made this rotation much more noticeable if used, but we account for declination elsewhere and IMU data is already in the ENU frame so no yaw_offset was used.

I live and test close to the meridian of my UTM zone, so this angle was always very small (+-0.07 degrees), so ran "unnoticed" (I attributed the slight variation to differences in state estimation or other system portions). When testing much further away from the meridian, the erroneous rotation was very obvious as seen in the plotting above.

---

Originally posted by hapy-capy with karma: 33 on 2022-12-29

This answer was ACCEPTED on the original site

Post score: 1