IMU + Odometry Robot Localization Orientation Issue

Question

Hello I am trying to use robot localization package for fusing IMU and Wheel Encoder Odometry such that x and y velocities are taken from odometry data and heading is taken from imu.

However I am getting this issue such that fused localization is not really paying attention to the heading from the IMU. Such that the ekf output just goes down whatever heading the odometry gives while still facing the correct imu direction.

For example, in the picture below , I have my rover going forward and then turn right 90 degrees and then go forward. Blue is wheel odometry (It is very off when coming up with yaw) and the red is the ekf output.

I have also attached a bag file of this test.

Here is my ekf params:

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

  odom0: odometry/wheel
  odom0_config: [false, false, false,
                 false, false, false,
                 true,  true,  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,  true,
                false, false, true,
                false,  false,  true,
                false,  false, true]
                
                
                
  imu0_nodelay: false
  imu0_differential: false
  imu0_relative: false
  imu0_queue_size: 10
  imu0_remove_gravitational_acceleration: true

Thoughts?

---

Originally posted by jawsqb on ROS Answers with karma: 33 on 2019-08-28

Post score: 1

---

Original comments

Comment by Eisenhorn on 2019-08-29:
Why do you filter out yaw' int the odom0_config? Mybe can you also show an image of the fused odom output?

Here is a link with a a walktrough on configuring the ekf

http://docs.ros.org/melodic/api/robot_localization/html/configuring_robot_localization.html

Comment by jawsqb on 2019-08-29:
The odom fused output is the red arrows, that is fusion of both the odom and the imu.

Reason why I took out the yaw was because the wheel odometry is very off when it comes to turning so I wanted the yaw to be only fused from the IMU.

I have already tried using the params from there however I have the same issue.

Answer 1

Try these, I just pulled this out of one of my config files

imu0: /imu
imu0_config: [
    false,  false,  false,  # x, y, z
    true,   true,   true,   # roll, pitch, yaw robot_localization recommends fusing orientation for IMU
    false,  false,  false,  # x vel, y vel, z vel
    false,  false,  false,  # roll vel, pitch vel, yaw vel
    false,  false,  false   # x accel, y accel, z accel (ideal want true true false)
]

odom0: /odom
odom0_config: [
    false,  false,  false,  # x, y, z
    false,  false,  false,  # roll, pitch, yaw
    true,   true,   true,   # x vel, y vel, z vel
    false,  false,  false,  # roll vel, pitch vel, yaw vel
    false,  false,  false   # x accel, y accel, z accel
]

---

Originally posted by stevemacenski with karma: 8272 on 2019-08-29

This answer was NOT ACCEPTED on the original site

Post score: 3

Answer 2

Four questions:

1): Do you have a second EKF estimating map_frame:? If you do, start with only one EKF for now. From the documents:
Note If your system does not have a map_frame, just remove it, and make sure world_frame is set to the value of odom_frame.

2): Why are you fusing in Z velocity from your IMU into the EKF?

imu0: /imu/data
imu0_config: [false, false, false,
                    false,  false,  true,
                    false, false, true, # This one here?
                    false,  false,  true,
                    false,  false, true] # Are you using this value? ie: two_d_mode: true? Doesn't look like you are.

I don't know if there is any IMU that reports Z velocity, but if yours does I would be interested to know.

Also, are you estimating Z position/velocity? If no sensor is correcting the Z accelerations and your two_d_mode is somehow being set to true you might see interesting results in Z.

3. You are fusing in Z angular velocity, what IMU driver are you using? I have found that some drivers report angular velocity and orientation in two different methods. It is incredibly hard to properly mount the IMU and have them physically match. (This is due to flipping from NED to ENU by doing something like this: X->Y Z->-Z) the proper way is to do a Quaternion multiply: https://github.com/ros-drivers/microstrain_mips/issues/4

4. I don't see the attached bagfile, am I missing it somewhere?

---

Originally posted by SamsAutonomy with karma: 68 on 2019-09-05

This answer was NOT ACCEPTED on the original site

Post score: 1

Answer 3

Just as update, extremely sorry for the lateness in reply.

So i was misinterpreting how ekf was fusing the wheel odometry and the IMU. Despite having orientation correct from IMU the X,Y position odometry from the wheels was very off due to a differential drive odometry calculation node having some wrong parameters.

Specifically the wheel width between the two wheels was too small and I had to increase by almost 2 times to get accurate turning (I did this by just guess and check) . Now the ekf output is matching the actual robot movement.

Also I have ekf also fusing position estimate from an indoor GPS which is now giving a more accurate position estimate.

I am however getting a different set of issues now regarding orientation, the y direction movement is flipped in the global frame... Should I create new post for that issue?

---

Originally posted by jawsqb with karma: 33 on 2019-09-19

This answer was ACCEPTED on the original site

Post score: 1

---

Original comments

Comment by jayess on 2019-09-19:
Is this an answer or an update?