# IMU_GPS robot_localization and navsat_transform_node

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:

the launch file is here:

<launch>
<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
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 ...
edit retag close merge delete

the new bag file is here:NEW_bagfile

( 2018-03-09 03:56:26 -0500 )edit

Sort by » oldest newest most voted

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" />

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').
more

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.

more

thanks for the reply,the imu is a MPU 6150 which has no magnetometer ╯０╰ . 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.

( 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.

( 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" />

( 2018-03-05 21:16:57 -0500 )edit