IMU_filter_madgwick and robot_localization for integrating GPS in outdoor navigation

asked 2022-05-03 10:32:22 -0500

Sid05
15 ●3 ●7 ●10

updated 2022-06-12 15:10:55 -0500

Hi,

I am trying to use the the IMU_filter_madgwick to filter the IMU and feed the filtered IMU to robot_localization to improve the localization for GPS based outdoor navigation to fix the issue mentioned in here. But I am unable to see to any improvements, can someone tell me what I am doing wrong ?

Regards,

EKF_NAVSAT.YAML

ekf_se_odom:
  frequency: 30
  sensor_timeout: 0.1
  two_d_mode: true  #false
  transform_time_offset: 0.0
  transform_timeout: 0.0
  print_diagnostics: true
  debug: false

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

  odom0: odom    #odometry/wheel
  odom0_config: [true, true, false,
                 false, false, true,
                 false, false, false,
                 false, false, true,
                 false, false, false]
                #  [false, false, false,
                #  false, false, false,
                #  true,  true,  true,
                #  false, false, false,
                #  false, false, false]

  odom0_queue_size: 10
  odom0_nodelay: true
  odom0_differential: false
  odom0_relative: false

  imu0: imu/data_filtered
  imu0_config: [false, false, false,
                false, false, true,
                false, false, false,
                false, false, true,
                true,  true, false] 
              #  [false, false, false,
              #   true,  true,  false,
              #   false, false, false,
              #   true,  true,  true,
              #   true,  true,  true]
  imu0_nodelay: false
  imu0_differential: false
  imu0_relative: false
  imu0_queue_size: 10
  imu0_remove_gravitational_acceleration: true

  use_control: false

  process_noise_covariance: [1e-3, 0,    0,    0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                             0,    1e-3, 0,    0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                             0,    0,    1e-3, 0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                             0,    0,    0,    0.3,  0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                             0,    0,    0,    0,    0.3,  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.5,   0,     0,    0,    0,    0,    0,    0,    0,
                             0,    0,    0,    0,    0,    0,    0,     0.5,   0,    0,    0,    0,    0,    0,    0,
                             0,    0,    0,    0,    0,    0,    0,     0,     0.1,  0,    0,    0,    0,    0,    0,
                             0,    0,    0,    0,    0,    0,    0,     0,     0,    0.3,  0,    0,    0,    0,    0,
                             0,    0,    0,    0,    0,    0,    0,     0,     0,    0,    0.3,  0,    0,    0,    0,
                             0,    0,    0,    0,    0,    0,    0,     0,     0,    0,    0,    0.3,  0,    0,    0,
                             0,    0,    0,    0,    0,    0,    0,     0,     0,    0,    0,    0,    0.3,  0,    0,
                             0,    0,    0,    0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0.3,  0,
                             0,    0,    0,    0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0.3]

  initial_estimate_covariance: [1e-9, 0,    0,    0,    0,    0,    0,    0,    0,    0,     0,     0,     0,    0,    0,
                                0,    1e-9, 0,    0,    0,    0,    0,    0,    0,    0,     0,     0,     0,    0,    0,
                                0,    0,    1e-9, 0,    0,    0,    0,    0,    0,    0,     0,     0,     0,    0,    0,
                                0,    0,    0,    1.0,  0,    0,    0,    0,    0,    0,     0,     0,     0,    0,    0,
                                0,    0,    0,    0,    1.0,  0,    0,    0,    0,    0,     0,     0,     0,    0,    0,
                                0,    0,    0,    0,    0,    1e-9, 0,    0,    0,    0 ...

(more)

answered 2022-05-31 03:58:21 -0500

Tom Moore

flag of United Kingdom of Great Britain and Northern Ireland

13689 ●74 ●240 ●232 http://github.com/ayrton04

updated 2022-07-04 03:28:25 -0500

Can you help me understand your yaw_offset value? You have your magnetic_declination_radians parameter set correctly for The University of Edinburgh (hello from a fellow Edinburgh resident!), but I am not clear how you calculated your yaw_offset. Point your IMU at magnetic north. If it reads 0, then your yaw_offset should be pi/2.

If there is no output on /odometry/gps, then navsat_transform_node is not receiving an input that it needs. Please post a sample message from every sensor input.

EDIT in response to comments:

So my IMU produces a diiferent value when pointing to magnetic north and east with each trial

Are you indoors for these trials? Magnetometers are notoriously erroneous when there is any kind of inteference from electrical sources, ferrous metals, etc. I find mags inside buildings are borderline useless.

What I said before is still true: if navsat_transform_node is not publishing, then either (a) it's not receiving all the data it needs, or (b) something about the data it is receiving is erroneous.

Looking at your config, I see this:

<node pkg="robot_localization" type="navsat_transform_node" name="navsat_transform" clear_params="true">
  <remap from="odometry/filtered" to="odometry/filtered_map"/>
  <remap from="imu/data" to="imu/data"/>
  <remap from="gps/fix" to="fix"/>
</node>

Can you do rosnode info navsat_transform and look at all the subscriptions it has, and then make sure you can echo each one?

Also, I see your IMU data has a frame_id of imu_link. Do you have a transform defined from base_footprint to imu_link? The nodes won't be able to use the IMU data at all without it. Run rosrun tf tf_echo base_footprint imu_link.

edit flag offensive delete link

Comments

Hi,

Thank you for replying @Tom Moore

So my IMU produces a diiferent value when pointing to magnetic north and east with each trial (measured direction with an app) , so the values commeneted next to the yaw_offset parameter in the yaml file is for different trials. The IMU sensor I use is this . I assumed the IMU behaved that way because of some bias and so I thought the filter would help fix this but it did not. I am trying to find if any sort of calibration is required for the sensor.

Unfortuntely, it will be later in this week when I get my chance to work with the robot again , when I do get that chance, I will record a rosbag and also provide a sample of the topic.

Sid05 ( 2022-05-31 05:26:11 -0500 )edit

Hi,

Sorry for the late update. I have now updated a sample message from each sensor input as you asked @Tom Moore.

Sid05 ( 2022-06-12 15:11:44 -0500 )edit

add a comment

IMU_filter_madgwick and robot_localization for integrating GPS in outdoor navigation

EKF_NAVSAT.YAML

1 Answer

Comments

Question Tools

Stats

Related questions

IMU_filter_madgwick and robot_localization for integrating GPS in outdoor navigation edit

EKF_NAVSAT.YAML

1 Answer

Comments

Question Tools

Stats

Related questions

IMU_filter_madgwick and robot_localization for integrating GPS in outdoor navigation