Rosanswers logo

I am trying to estimate the position of a robot using robot_localization. There are ONLY two sensors used in the problem: an IMU and a GPS receiver. After reading the tutorials about robot_localization and studying many threads in the ros-answer website, I am still a little confused about how to structure the overall estimation process. I would greatly appreciate if someone with experience in this topic can offer some suggestions.

I understand I need to use navsat_transform_node in order to integrate GPS into robot_localization, but navsat_transform_node requires three inputs. In addition to IMU & GPS, it requires an odometry input, which is not available in my system. To solve this issue, I first feed IMU (sensor_msgs/Imu) and GPS (sensor_msgs/NavSatFix) measurements to utm_odometry_node, which is a node of the gps_common package. The output of utm_odometry_node is of the type nav_msgs/Odometry, and it is feed to navsat_transform_node along with the original IMU and GPS measurements. The output of navsat_transform_node, named odometry/gps, is then feed to ekf_localization_node with the original IMU measurements.

I was wondering if this is the correct structure of the estimation process. Any comments and suggestions will be appreciated!

Originally posted by AK47 on ROS Answers with karma: 73 on 2014-12-25

Post score: 7


1 Answer 1


Rosanswers logo

No, I don't think your setup will work, although I haven't thought through it in great depth. In any case, it's not the way it's intended to be used. The odometry input to navsat_transform_node can just be your ekf_localization_node output (it defaults to odometry/filtered). navsat_transform_node needs the third input (the odometry from your state estimate) because it converts the GPS data into the coordinate frame of that message. If your robot starts out, for example, indoors, and then moves outdoors, you need to know its pose estimate at the moment it starts receiving GPS in order to make the transformed GPS data consistent with your current state estimate.

For you, as soon as your IMU data is fed to the filter, ekf_localization_node will produce a state estimate, at which point navsat_transform_node will have all the data it needs.

EDIT in response to question:

Your final setup will be this:


  • Inputs

    • IMU
    • Transformed GPS data as an odometry message (navsat_transform_node output)
  • Outputs

    • Odometry message (this is what you want to use as your state estimate for your robot)


  • Inputs

    • IMU
    • Raw GPS (NavSatFix)
    • Odometry (output of ekf_localization_node)
  • Outputs

    • Transformed GPS data as odometry message

The data path is circular, but it's necessary. Once navsat_transform_node gets the first IMU message, it drops the subscription.

Originally posted by Tom Moore with karma: 13689 on 2014-12-26

This answer was ACCEPTED on the original site

Post score: 13

Original comments

Comment by AK47 on 2014-12-26:
Tom, thank you very much. If I understand correctly, the correct setup is to feed IMU data to ekf_localization_node, and then feed the output of this node. along with IMU and GPS data, to the navsat_transform_node to get the final estimation. Is this the correct setup? Thanks!

Comment by Tom Moore on 2014-12-26:
No, sorry. See the answer edit.

Comment by AK47 on 2014-12-26:
Tom, many thanks! I configure my estimation in the way as you suggested, and it seems to be working!

Comment by Zoid on 2017-02-19:

I am really interested in the topic! Could you please post your launch files here to familiarizamyselfof how to setup my similar project? Thank you!

Comment by rz on 2018-04-19:
Hello AK47

I am really interested in the topic! Could you please post your launch files here to familiarizamyselfof how to setup my similar project? Thank you!

Comment by rezafirouzi on 2019-10-22:
Hi Tom, Are you sure the navsat_transform_node drops subscription to odometry message(after first message)? What I see in source code is that the subscription to IMU is shutdown after the first message. But not the Odometry. Please clarify this issue.

Comment by Tom Moore on 2019-11-04:
Yes, that is correct. Edited, thanks.

Comment by ClintQ on 2021-03-19:
Hi Tom, The setup that you have captured would require another ekf_localization_node correct? To establish the odom->base_link transform and then this setup for the map->odom transform. My question is what is the right odometry message to use for the input to the ekf_localization_node that is creating the odom->base_link transform if the odometry/gps output is feeding into the odometry input of the ekf_localization_node creating the map->odom transform?

The circular reference gets a little confusing. Thank you.

Comment by Tom Moore on 2021-03-22:
@ClintQ if you haven't already, would you mind asking that as a new question? Thanks.

Comment by lxg on 2021-07-06:
@Tom Moore, please take a look at my question. Despite the navsat_transform node not publishing the transformed GPS data, I am having two robots both starting at [0 0 0], even if am sure this is wrong. How can I ensure that at least the GPS positioning is used? Because independent GPS alone is giving better results than fusion. which should not be the case at all. Thanks


Your Answer

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