Skip to content

Are localization warnings expected? #41

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
bsb808 opened this issue Apr 25, 2021 · 1 comment
Open

Are localization warnings expected? #41

bsb808 opened this issue Apr 25, 2021 · 1 comment
Assignees

Comments

@bsb808
Copy link
Collaborator

bsb808 commented Apr 25, 2021

When I run the VORC localization example from https://github.com/osrf/vorc/wiki/sensors

roslaunch vorc_gazebo marina.launch verbose:=true

and then

roslaunch vorc_gazebo localization_example.launch

I get the following transform warnings - perhaps a state publisher issue?

[ WARN] [1619375160.924654495, 648.733000000]: Transform from cora/imu_link to cora/base_link was unavailable for the time requested. Using latest instead.

[ WARN] [1619375161.138304949, 648.946000000]: Transform from cora/gps_link to cora/base_link was unavailable for the time requested. Using latest instead.

[ WARN] [1619375162.926686795, 650.733000000]: Transform from cora/imu_link to cora/base_link was unavailable for the time requested. Using latest instead.

[ WARN] [1619375163.239991691, 651.046000000]: Transform from cora/gps_link to cora/base_link was unavailable for the time requested. Using latest instead.

In the above, I'm using Melodic. There are other issues with Noetic - see bsb808/mrc_notes#4

@caguero
Copy link
Collaborator

caguero commented Apr 27, 2021

I remember seeing these warnings since the beginning but never paid much attention to them. It looks like this is a discrepancy between the EKF update rate and the sensor update rate.

https://answers.ros.org/question/300345/robot-localization-package-transform-from-base_link-to-odom-was-unavailable-for-the-time-requested-using-latest-instead-imugps/

In the upper question, there's a reply with two potential workarounds:

You have two options:

a) Change your transform_time_offset EKF parameter to some small positive value. This will future-date its transform it's generating.

b) Set predict_to_current_time to true for the EKF. That will force the EKF to make a prediction to the current ROS time before publishing, rather than just publishing the state estimate at the time of the most recent measurement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants