Rosanswers logo

UPDATE I have changed the yaw_offset to 0 instead of 3.14. This has caused /odometry/filtered and odometry/gps to give much better results.


I have a TurtleBot3 robot with a GPS receiver. I am running ROS2 Dashing on Ubuntu 18.04 and a Raspberry Pi 3 Model B+. The transformation between /odom and /base_link is done in the TurtleBot3 bringup process. When I listen to the /odom everything seems good here. NB! The odometry topic has odometric data fused with IMU data. This is done in the hardware driver from ROBOTIS. In /odom: When I drive the robot forward, x-position increases. Moving to the left increases y-position. Turning counterclockwise around z gives an increase in yaw, so everything seems good here. I want to navigate outside so I want to use my GPS data for position information, and use the fused odometry and IMU data for orientation. I have set up an extended Kalman filter using the ekf_node from robot_localization and the navsat_transform node. The setup of these can be seen in the .yaml files below together with the launch file.

I have a tf2 transformation in the launch file since my GPS is mounted 23 centimeters above base_link and 8 centimeters behind. I have attached a picture (gps_transform) where this transform can be seen in rviz. It appears to be looking alright.

In the setup of the navsat_transform node I have a yaw_offset of 3.14.(Changed to 0 after update to post.) When I rotate my robot so that the imu_link x axis is pointing west I read 0 in yaw. From what the documentation says most IMUs have either north or east heading so there might be an issue here.

I have attached a ros2bag where the robot is stationary from 0:00 to 1:50 and starts moving thereafter named ekf_04_26-17_27 + a ros2bag with the new yaw_offset called ekf_28_24.


  1. As the robot is moving forward the /odom is increasing in x as expected. However, /odometry/filtered is decreasing in y axis and the same goes for odometry/gps. How can that be? I suspect this may have something to do with the yaw_offset I have supplied to the navsat_transform node. UPDATE: This was caused by the wrong yaw_offset finding the correct yaw_offset solved this issue.

  2. I can see that my /odometry/gps starts in position XYZ (0.08, 0.0, -0.23) from the transform I would expect the opposite XYZ (-0.08, 0.0, 0.23). Is something wrong with the transform itself or is it possible that the problem is arising from some other misconfiguration of the ekf setup? UPDATE: I am not sure that this is even a problem. It might be the correct transform. I just have a hard time grasping this one. Knowing that /odometry/gps is given in the map(world frame) and my transform is defined from /base_link to /gps my immediate expectation does not make sense.

  3. At the beginning map, odom, base_link, imu_link and gps are all placed around the same place with the x_axises pointing in the same direction. When the robot starts moving the map frame starts moving away from the odom frame. (This can be seen in the “map_odom.webm” screen recording(old yaw_offset) + “odometry_filtered_in_map_odom.webm” screen recording new yaw_offset). The transformation between /odom and /map is coming from the ekf_node. I don’t have a map frame prior to running the ekf as I assumed that ekf creates one. Is this correct? Also, should /map leave /odom? From REP-105, I understand that /odom is anchored in /map so shouldn’t the transform from map -> odom and vice versa be static? UPDATE: I now believe that /map and /odom should leave each other in the rviz visualization. What rviz is showing is how the /base_link frame is positioned in both /map and /odom. And for my case /base_link is positioned differently, therefore should /map and /odom not be in the same place.

Link to bag file and video snippet https://drive.google.com/open?id=1ksf0XDbP5WqcC4gbdiuGuMazEuaQp_hc

Gps transform gps_transform

Yaml param file for ekf_node

    frequency: 30.0
    sensor_timeout: 0.1
    two_d_mode: true
    transform_time_offset: 0.0
    transform_timeout: 0.0
    print_diagnostics: true
    debug: false

    map_frame: map
    odom_frame: odom
    base_link_frame: base_link
    world_frame: map

    odom0: odom
    odom0_config: [false, false, false,
                  false, false, true,
                  false,  true, false,
                  false, false, false,
                  false, false, false]
    odom0_queue_size: 10
    odom0_nodelay: true
    odom0_differential: false
    odom0_relative: false

    odom1: odometry/gps
    odom1_config: [true,  true,  false,
                  false, false, false,
                  false, false, false,
                  false, false, false,
                  false, false, false]
    odom1_queue_size: 10
    odom1_nodelay: true
    odom1_differential: false
    odom1_relative: false

Yaml param file for navsat_transform node

    frequency: 30.0
    magnetic_declination_radians: 0.0849975346  # For lat/long  57.452989,  10.021515
    yaw_offset: 0.0 # Changed from 3.14159265359 after update to this post
    zero_altitude: false
    broadcast_utm_transform: true
    publish_filtered_gps: true
    use_odometry_yaw: false
    wait_for_datum: false

Launch file

from launch import LaunchDescription
from ament_index_python.packages import get_package_share_directory
import launch_ros.actions
import os
import yaml
from launch.substitutions import EnvironmentVariable
import pathlib
import launch.actions
from launch.actions import DeclareLaunchArgument

def generate_launch_description():
    return LaunchDescription([

            cmd=['ros2', 'run', 'tf2_ros', "static_transform_publisher",
            "-0.08", "0.00", "0.23", "0", "0", "0", "base_link", "gps"],


            parameters=[os.path.join('/home/ubuntu/loc_nav_ws/src/turtle_localization/params', 'ekf_filter_map.yaml')],

            parameters=[os.path.join('/home/ubuntu/loc_nav_ws/src/turtle_localization/params', 'navsat_transform.yaml')],
            remappings=[("imu/data", "imu")]

Originally posted by DanielRobotics on ROS Answers with karma: 42 on 2020-04-27

Post score: 1

Original comments

Comment by Tom Moore on 2020-06-24:
Would you say that your update above answers this question, such that we can mark it as answered? Sorry for not looking at this sooner.

Comment by DanielRobotics on 2020-06-24:
Yes, it can be marked answered


1 Answer 1


Rosanswers logo

Original question was edited and answered above:

UPDATE I have changed the yaw_offset to 0 instead of 3.14. This has caused /odometry/filtered and odometry/gps to give much better results.

Originally posted by Tom Moore with karma: 13689 on 2020-06-24

This answer was ACCEPTED on the original site

Post score: 2


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.