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

robot_localization: odometry/filtered going to zero when using IMU

asked 2020-12-07 07:36:59 -0500

rezenders gravatar image

Hello,

I am trying to use the ekf_localization_node to fuse odom and IMU data with a simulated robot in gazebo. In my simulation the robot starts in a position different from (0,0,0), something like (18, 2, 0). Therefore, the /odom topic is also (18, 2, 0) when the simulation starts. When using the ekf_localization node if I use only odom the filtered odom seems to be working, but when I add the IMU the odom/filtered starts at (0,0,0) which is wrong in this case, how can I set up the IMU to make this work?

The ekf params that I am using:

frequency: 30

silent_tf_failure: false
sensor_timeout: 0.1

two_d_mode: true

transform_time_offset: 0.0
transform_timeout: 0.0

print_diagnostics: true

debug: false

debug_out_file: /path/to/debug/file.txt

publish_tf: true

publish_acceleration: false

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

odom0: /odom

odom0_config: [true,  true,  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

imu0: /imu_pub
imu0_config: [false, false, false,
              true,  true,  true,
              false, false, false,
              true,  true,  true,
              true,  true,  false]
imu0_nodelay: false
imu0_differential: false
imu0_relative: false
imu0_queue_size: 5
imu0_pose_rejection_threshold: 0.8                 # Note the difference in parameter names
imu0_twist_rejection_threshold: 0.8                #
imu0_linear_acceleration_rejection_threshold: 0.8  #

imu0_remove_gravitational_acceleration: false

use_control: true
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, 0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                           0,    0,    0,    0,    0.03, 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.025, 0,     0,    0,    0,    0,    0,    0,    0,
                           0,    0,    0,    0,    0,    0,    0,     0.025, 0,    0,    0,    0,    0,    0,    0,
                           0,    0,    0,    0,    0,    0,    0,     0,     0.04, 0,    0,    0,    0,    0,    0,
                           0,    0,    0,    0,    0,    0,    0,     0,     0,    0.01, 0,    0,    0,    0,    0,
                           0,    0,    0,    0,    0,    0,    0,     0,     0,    0,    0.01, 0,    0,    0,    0,
                           0,    0,    0,    0,    0,    0,    0,     0,     0,    0,    0,    0.02, 0,    0,    0,
                           0 ...
(more)
edit retag flag offensive close merge delete

Comments

Actually it is standard practice for the odom frame to be initialized where the robot starts. So I think it is actually the first case, where the robot odom starts at (18,2) that is mistaken

JackB gravatar image JackB  ( 2020-12-08 11:11:58 -0500 )edit

I spawned my model using the gazebo_ros spawn_model node passing the arguments with the coordinates I wanted, do you know if I should do it in a different way? But I wonder if the odom frame was at 0,0,0 for my robot, what would happen if I spawned another one in a different position? Wouldn't it be dislocated for the 2nd robot? I guess the odom is in a fixed position in gazebo to prevent this?

rezenders gravatar image rezenders  ( 2020-12-08 15:59:52 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2020-12-09 05:04:30 -0500

Tom Moore gravatar image

Do you need your EKF coordinates to match the coordinate frame of Gazebo?

The issue is just one of timing. If you don't supply an initial state, the first measurement you receive is used to initialise the filter. When you start with just odom data, the first measurement the filter gets puts the state estimate where Gazebo says it is.

When you add the IMU, my guess is the filter receives an IMU measurement before an odometry measurement. Since the IMU doesn't have pose data, it initialises the filter to a (0, 0) position, but with the given orientation.

Anyway, once you receive some odometry measurements, the filter should still move to the odometry pose, though it may take a few measurements.

If it were me, I'd not worry about whether the coordinate frame from Gazebo matches the EKF one. I'd just fuse wheel encoder and IMU _velocity_ data. The filter will always start at the origin, but it'll be consistent.

edit flag offensive delete link more

Question Tools

1 follower

Stats

Asked: 2020-12-07 07:36:59 -0500

Seen: 548 times

Last updated: Dec 09 '20