ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Unexpected output of robot_localization EKF

asked 2020-04-27 04:37:39 -0500

DanielRobotics gravatar image

updated 2020-04-29 04:11:31 -0500

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 ...

edit retag flag offensive close merge delete


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.

Tom Moore gravatar image Tom Moore  ( 2020-06-24 02:15:09 -0500 )edit

Yes, it can be marked answered

DanielRobotics gravatar image DanielRobotics  ( 2020-06-24 02:39:58 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2020-06-24 02:42:10 -0500

Tom Moore gravatar image

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.

edit flag offensive delete link more

Question Tools



Asked: 2020-04-27 04:37:39 -0500

Seen: 520 times

Last updated: Jun 24 '20