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

IMU_GPS robot_localization and navsat_transform_node

asked 2018-03-04 06:33:50 -0500

omoyouo gravatar image

updated 2018-03-04 06:55:01 -0500

Hi everyone, I have some car GPS data (about 1Hz) in my hand, and there is an electronic device built-in IMU in the car to collect IMU data (about 1KHz). The direction of the IMU on the car is the Z axis forward, the X axis right, and the Y axis point to the ground.However, because GPS will drift (some have left the road), it can not be used as accurate data for positioning algorithms.So I decided to use the robot_localization package to put the two kinds of data together, generating new, more accurate GPS data for future use.And I have referred to this post's answer ( https://answers.ros.org/question/2000... ). But my current program can not get the output (even if it is not accurate), I hope you can help me analyze the reasons. In addition, I finally hope to get GPS or UTM data. Thank you!

the rqt pic is here:

Imgur

the launch file is here:

<launch>
  <rosparam command="load" file="$(find robot_localization)/params/ekf_imu_gps.yaml" />
  <node pkg="robot_localization" type="ekf_localization_node" name="ekf_se_map" clear_params="true">
    <remap from="odometry/filtered" to="odometry/filtered_map"/>
  </node>
  <node pkg="robot_localization" type="navsat_transform_node" name="navsat_transform" clear_params="true">
    <remap from="odometry/filtered" to="odometry/filtered_map"/>
  </node>
</launch>

the pramater file is here:

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

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

  # odom0: odometry/gps
  odom0: odometry/gps
  odom0_config: [true, true, false,
                 false, false, false,
                 false, false, false,
                 false, false, false,
                 false, false, false]
  odom0_queue_size: 10
  odom0_nodelay: true
  odom0_differential: false
  odom0_relative: false

  imu0: imu/data
  imu0_config: [false, false, false,
                false, false, 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-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,    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,    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,    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,     1e-9,  0,    0,
                                0,    0,    0,    0 ...
(more)
edit retag flag offensive close merge delete

Comments

the new bag file is here:NEW_bagfile

omoyouo gravatar image omoyouo  ( 2018-03-09 03:56:26 -0500 )edit

2 Answers

Sort by » oldest newest most voted
1

answered 2018-03-19 06:18:32 -0500

Tom Moore gravatar image

updated 2018-03-19 06:20:30 -0500

I haven't looked at the bag data, but just a few things I note looking at your data and configuration.

  1. Linear acceleration: I'd set them all to false for your IMU. The filter does not have active bias correction, so unless you have a velocity reference (e.g., wheel encoder or visual odometry), the integration of acceleration data will cause your state estimate to start running away rapidly. It'll snap back whenever it gets a GPS measurement, but the state estimate will get progressively worse.
  2. Change your IMU message frame_id to imu_link. Also, what units are your IMU velocities and the static_transform_publisher in? ROS uses radians, and those look suspiciously like degrees.
  3. If your IMU is mounted as you say, then I'd expect this. Keep in mind that tf and tf2 assume that the order is X Y Z yaw pitch roll, though I believe they are applied extrinsically with roll, then pitch, then yaw. Experiment with values here and look at the frame in rviz to confirm.

    <node pkg="tf2_ros" type="static_transform_publisher" name="transform" args="0 0 0 -1.5707963268 0 -1.5707963268  base_link imu_link" />
    
  4. Get rid of the leading slash in your GPS message.
  5. Did you define a base_link->gps transform? You're going to need one, if you gave your GPS message a frame_id. There is a bug at the time of this writing, though, so I suggest making the transform the identity (all zeros) for now. Also, get rid of the leading slash in your GPS frame ('/gps').
edit flag offensive delete link more
0

answered 2018-03-05 08:20:39 -0500

stevejp gravatar image

I'm not sure what kind of results you can expect when you don't have vehicle odometry and you aren't fusing any absolute yaw measurements, but I guess it doesn't hurt to try. I would start with taking a closer look at the IMU data you're working with.

First, I would make sure that the numbers being reported by your IMU are realistic. Just looking at the bag file, the angular velocities look suspicious, and it looks like your linear accelerations are being reported in g's. If you can, look at the IMU data when the vehicle is stationary and make sure the numbers make sense.

Second, make sure that your IMU data is being reported in the correct ENU frame (i.e., what r_l and navsat_transform are expecting). The details of the IMU co-ordinate frame are outlined in REP-105.

Out of curiosity, what IMU are you working with? If it has a magnetometer you might consider using the madgwick filter or complementary filter to get an orientation estimate.

edit flag offensive delete link more

Comments

thanks for the reply,the imu is a MPU 6150 which has no magnetometer ╯0╰ . Accelerometer is indeed g as a unit, andI remake the bag file. At the same time, I also noticed the problem with the coordinate system, so I added the coordinate system transformation.

omoyouo gravatar image omoyouo  ( 2018-03-05 21:12:55 -0500 )edit

because I did not know the direction of the specific IMU, but according to the data, y should point to the sky and most of x was positive, so it should be the forward direction. Because I am ros beginner, so there may be a lot of configuration errors, please forgive me.

omoyouo gravatar image omoyouo  ( 2018-03-05 21:13:44 -0500 )edit

the transform is here:

<node pkg="tf" type="static_transform_publisher" name="transform" args="0 0 0 0 0 90  base_link imu_link 100" />
omoyouo gravatar image omoyouo  ( 2018-03-05 21:16:57 -0500 )edit

Question Tools

4 followers

Stats

Asked: 2018-03-04 06:33:50 -0500

Seen: 888 times

Last updated: Mar 19 '18