0
$\begingroup$

Rosanswers logo

I have robot_localization working pretty well, but I am noticing that it introduces a lag into the pose update, particularly when turning. On rviz, you see the laser hit pattern move first, then the robot pose updates and "catches up" to the laser pattern. Going to goals and avoiding obstacles are working pretty well and the accuracy of the overall pose is pretty good when the robot stops moving. In general, simple translations do not show this effect.

I am only using vx and vYaw as inputs to robot_localization, from wheel odometry and a gyro, respectively. I tried varying the covariance of vYaw, but the problem persists over a wide range of covariances.

Suggestions?


Originally posted by dan on ROS Answers with karma: 875 on 2015-11-16

Post score: 2


Original comments

Comment by Procópio on 2016-01-04:
hi dan, I could not download your launch file, dropbox says it is gone. can you please share it again? thanks.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

I'd have to see input messages and your launch file. Also, see this question. In addition, try increasing the process_noise_covariance parameter for yaw velocity (not the measurement covariance).

EDIT

Looking at your bag and launch files, a few things jump out at me. There are things that could be causing your issue, and things that are probably unrelated, but should be fixed.

Potential Causes for Delay

  1. The EKF and UKF in robot_localization are typically subject to a two-spin-cycle delay. Part of this is due to the use of TF message filters. I've managed to get this down to one cycle in the latest indigo-devel source. However, part of your problem is that you have your frequency set to 20 Hz. If every measurement is delayed by two spin cycles, then you're looking at a lag of 0.1 seconds, which is quite a long time. This also appears to align with what I'm seeing when I plot the IMU input for yaw velocity and the filter output. Grab the latest source and see if that brings it down a bit. Then up the frequency parameter, or decrease the sensor_timeout parameter (or both).
  2. Maybe up the process_noise_covariance a bit more for yaw velocity.
  3. You have yaw set to true for your IMU data, which means you are (presumably) using a magnetometer. I personally find magnetometers to be nearly useless indoors, but YMMV.

Other Things That You Should Correct

  1. Despite the use of yaw information from your IMU, you have your initial_estimate_covariance yaw value set to 0.01. That will make the filter slow to integrate the yaw measurements initially, which may or may not have been your intention. Making matters worse is that your yaw covariance value in your measurement is 1000000.0, which will effectively make the filter ignore those measurements.

  2. Your IMU is reporting at a rate of 9.89 Hz, which seems low for an IMU, and makes me wonder if it's supposed to be 10, and there's a delay in the handling of the raw data. If you can up the frequency on your IMU (and the EKF), then it might be helpful.

  3. You have nothing measuring Y velocity. If your robot cannot move laterally, then go ahead and set Y velocity to true for your odometry, and make sure the odometry data has a small covariance value for Y velocity.


Originally posted by Tom Moore with karma: 13689 on 2015-11-19

This answer was ACCEPTED on the original site

Post score: 1


Original comments

Comment by dan on 2015-12-08:
Here are bag files, with and without robot_localization running: https://www.dropbox.com/s/5io70piu98wr8y2/robot_localization.bag?dl=0 https://www.dropbox.com/s/dgna06kw5pq0i6y/no_robot_localization.bag?dl=0 Launch file: https://www.dropbox.com/s/fwsf5hc6vgdldoo/my_bot_robot_localization

Comment by dan on 2015-12-08:
In the case without robot_localization, we are just publishing the raw wheel odometry and gyro yaw angle without filtering. You can see that with robot_localization, translation is fine but rotation seems to momentarily go the wrong way, as revealed by the laser scan then "catches up" but with lag

Comment by dan on 2015-12-26:
Thanks for the feedback. I tried all of your suggestions and the lag has improved, but not resolved. Using the dev version of code now. The parameter that made the most difference was the update rate of the filter (to 50 Hz). I increased the IMU rate as well (also to 50 Hz).

Comment by dan on 2015-12-26:
I increased the process_noise_covariance and the initial_estimate_covariance and he sensor_timeout. I set Y velocity to true and made its covariance small. These things did not seem to make much difference.

Comment by dan on 2015-12-26:
Here are the bag files with and without robot_localization running. When robot_localization is not running, the raw odometry is used without any filtering. amcl seems to track the pose better with the raw data. https://www.dropbox.com/sh/octco12yqsp8syj/AACaa6Hyk1u1G7Ahv4EO1J0Fa?dl=0

Comment by Tom Moore on 2015-12-28:
There will never be non-zero lag. You'll always be behind by ~1 spin cycle + the time required to integrate your measurement (the latter is why I am having you play with covariances). Not much to tell you at this point, other than to make sure your IMU driver itself isn't lagged.

Comment by dan on 2016-01-02:
Sounds good. Once again, thanks for the help.

Comment by toddsampson on 2016-06-02:
We are having a similar issue. Did you ever get this resolved?

Comment by Tom Moore on 2016-06-14:
I've seen this as well, and one thing to check is that your raw odometry isn't lagged. Try turning on the odom->base_link transform in your odometry source, then disable r_l, then run the LIDAR experiment again. Failing that, it's like a question of covariance.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.