ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

Robot_localization configuration (GPS, IMU, Odometry)

asked 2018-06-18 07:26:58 -0500

ce_guy gravatar image

updated 2018-06-25 04:59:51 -0500


I try to use the robot_localization package for a project where we have the following sensors:

  • IMU

  • Odometry by wheel encoders

  • GPS

After I have read the robot_localization documentation and seen the ROSCON presentation of Tom Moore I have the following setup:

  • ekf localization node with input of navsat_transform_node (odometry/gps), IMU and odom

  • navsat_transform node with input from ekf localization node (odometry/filtered) and IMU

My frame configuration is the following:

  • odom_frame: odom

  • base_link_frame: base_link

  • world_frame: odom

I have read in the "ekf_template.yaml" of the robot_localization package that I should set the world_frame to map when fusing a global absolute position and get the odom->base_link transform from somewhere else (another estimation node for example but I shouldn't fuse global data there).

In my configuration I am using the global position in both nodes (input for navsat_transform_node and the output of the node into ekf_localization_node)

Do I need to create a second ekf_localization_node with just continous data input and use the data output of this node as input into the first ekf_localization_node which just fuses two odometry sources (from navsat_transform_node and second ekf_localization_node) then?

Is the output of the first ekf_localization_node or the navsat_transform_node the most reliable then to use the pose for distance measuring or calculation of circle radius for example?

Thank you guys in advance!


We have the following configuration for ekf_localization_node (at the moment):

frequency: 30

sensor_timeout: 0.1

two_d_mode: false

transform_time_offset: 0.0

transform_timeout: 0.0

print_diagnostics: true

debug: false

debug_out_file: robot_localization_debug.txt

publish_tf: true

publish_acceleration: false

odom_frame: odom            # Defaults to "odom" if unspecified
base_link_frame: base_link  # Defaults to "base_link" if unspecified
world_frame: odom           # Defaults to the value of odom_frame if unspecified

odom0: /odom

odom0_config: [false,  false,  false,
               false, false, false,
               true, true, false,
               false, false, true,
               false, false, false]

odom0_queue_size: 2

odom0_nodelay: false

odom0_differential: false

odom0_relative: false

odom0_pose_rejection_threshold: 5
odom0_twist_rejection_threshold: 1

odom1: /odometry/gps
odom1_config: [true, true, true,
               false, false, false,
               false, false, false,
               false, false, false,
               false, false, false]

odom1_differential: false

odom1_relative: true

odom1_queue_size: 2

odom1_pose_rejection_threshold: 2

odom1_twist_rejection_threshold: 0.2

odom1_nodelay: false

imu0: /imu/data
imu0_config: [false, false, false,
              false,  false, true,
              false, false, false,
              false, false, true,
              true, false, false]
imu0_nodelay: false

imu0_differential: false

imu0_relative: true

imu0_queue_size: 5

imu0_pose_rejection_threshold: 0.8               

imu0_twist_rejection_threshold: 0.8

imu0_linear_acceleration_rejection_threshold: 0.8  

imu0_remove_gravitational_acceleration: true

use_control: false

stamped_control: false

control_timeout: 0.2

control_config: [true, false, false, false, false, true]

acceleration_limits: [1.3, 0.0, 0.0, 0.0, 0.0, 3.4]

deceleration_limits: [1.3, 0.0, 0.0, 0.0, 0.0, 4.5]

acceleration_gains: [0.8, 0.0, 0.0, 0.0, 0.0, 0.9]

deceleration_gains: [1.0, 0.0, 0.0, 0.0, 0.0, 1.0]

process_noise_covariance: [0.05, 0,    0,    0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                           0,    0.05, 0,    0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                           0,    0,    0.06, 0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                           0,    0,    0,    0.03 ...
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2018-06-19 05:40:39 -0500

Tom Moore gravatar image

updated 2018-06-25 10:01:47 -0500

Please post your configuration and launch files. It makes answering such questions easier.

I can say that this is a typical setup for GPS data:

EKF1: world frame is odom, fuse IMU and wheel encoders.

EKF2: world frame is map, fuse GPS, IMU, and wheel encoders

navsat_transform_node should listen to the output of EKF2.

As to which output to use, it doesn't really make sense to use the output of navsat_transform_node, unless you want to plot it in Google Earth or something. The output of EKF2 will be the most accurate pose, but is obviously subject to discontinuities from the GPS.

EDIT: your second solution is more in line with what I was thinking, yes. The example in the package isn't prescriptive; that is, I don't encourage you to stick to it necessarily, but it gives an idea of what's required to work with GPS data.

What is your second odometry source? The odom_gps data? Or another one?

I'll give you the same advice I give everyone: get your filters working with just IMU and wheel encoders. When that's done, add the GPS data.

I'm not sure how well this will work in a mapping context, but I know nothing about your setup.

edit flag offensive delete link more


Thank you very much for your answer! I have updated the question now with the configuration and launch files.

ce_guy gravatar image ce_guy  ( 2018-06-25 05:00:40 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2018-06-18 07:26:58 -0500

Seen: 2,413 times

Last updated: Jun 25 '18