Skip to content
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

Laser tf conflict with rviz2 but works fine with rviz 1 #573

Closed
Tahir-Rasheed-437 opened this issue Jul 10, 2020 · 5 comments
Closed

Laser tf conflict with rviz2 but works fine with rviz 1 #573

Tahir-Rasheed-437 opened this issue Jul 10, 2020 · 5 comments

Comments

@Tahir-Rasheed-437
Copy link

I am new user of ROS2. I am currently using ROS2-dashing. I have a vrep simulation of my Robot with all the topics (/odom, laser scans, etc). I am trying to visualize the scan data in rviz2. The required tf topics are generated in a node through a launch file with parameters use_sim_time true. I can see the stamp of the tf's are well according to the simulation time. But when i try to visualize the laser scan, it gives the following error.

[ERROR] [rviz2]: Lookup would require extrapolation into the future. Requested time 955741.25000 but the latest data is at time 955741.06250, when looking up transform from frame [laser_0] to frame [odom]
and
Could not transform from [laser_0] to [odom]

I tried ROS1 melodic and use the ROS1 bridge to see if the same error appears in ROS1 rviz(rviz1). Apparently it is working fine in ROS1 rviz without any error and showing the laser data completely fine. I have verified in tf_tree that all my tf's are available. What could be the possible mistake i have been doing? I am failed to understand as its working in rviz but not in rviz2. In the attached picture you can see ROS1 rviz in the left and rviz2 on the right.

rviz1 vs rviz2

@Tahir-Rasheed-437 Tahir-Rasheed-437 changed the title Laser tf conflict with rviz 2 but works fine with rviz 1 Laser tf conflict with rviz2 but works fine with rviz 1 Jul 10, 2020
@Martin-Idel
Copy link
Contributor

This could be related to #359 which only got merged recently (should be shipped with foxy). Do you have any way to try this out?

@Tahir-Rasheed-437
Copy link
Author

oh. so i have to shift to foxy now? I was trying to avoid that as i had some issues in compiling the libsimExtROS2Interface.(https://github.com/CoppeliaRobotics/simExtROS2Interface) that will generate communication of vrep with foxy.
For the tf issue in rviz2, i am using rviz in ROS1 using ros bridge but surely i can try to see if rviz2 in foxy is working fine or not.

@Martin-Idel
Copy link
Contributor

To see whether this actually fixes your problem, probably yes.

However, maybe #551 should be considered for a backport to dashing (and eloquent?) in any case as we have quite a few tickets related to this problem? @jacobperron maybe?

@Tahir-Rasheed-437
Copy link
Author

Tahir-Rasheed-437 commented Jul 20, 2020

Yes its fine in foxy. no error is generated from rviz2 in foxy. the message filter is surely a great help. I am going to close the issue.
Many thanks

@jacobperron
Copy link
Member

However, maybe #551 should be considered for a backport to dashing (and eloquent?) in any case as we have quite a few tickets related to this problem?

In lieu of a patch for #548, I think backporting #551 is a reasonable thing to do. I can take a look at making the backports.

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