Conversation
spin_once() limits the number of callbacks that can be called based on how quickly the gui updates. This results in lag when displaying tf frames. Use spin_some(max_duration) to execute all of the work available.
|
CI for this plus ros2/rclcpp#558 and ros2/system_tests#299
|
|
Wow, nice! |
wjwwood
left a comment
There was a problem hiding this comment.
Thanks this is a great improvement!
Long term I think I need to consider a different threading model for rviz, but the issue is that I believe some code that is run in ROS callbacks assumes that it is run in the main GUI thread (i.e. not while Qt is updating it's run loop) to avoid issues with thread-safety and accessing UI elements.
|
I continue to have the same issue even using the last patched version. You can replicate it running the dummy robot example:
At this point you will see the simulated laser scan on the oscillating link of the robot and you will notice how it is rendered in late respect to its reference frame.
|
|
@Myzhar would you mind making your comment a new issue on this repo? Once a pull request is merged it no longer appears on our waffle board, so comments on merged PRs tend to be forgotten. |
|
@sloretz sure 👍 |
This fixes ros2/ros1_bridge#133 . Displayed tf data was delayed because rviz wasn't able to call callbacks fast enough to service the transform listener subscription. This resulted in tf2 always having out of date transforms (see ros2/geometry2#71), and gave the mistaken impression that rviz2 was receiving data slower than rviz over the bridge.
To fix this executors now have a parameter
max_durationonspin_some(). This preventsspin_some()from blocking the gui update while allowing callbacks to be executed faster than the gui updates.rviz left, rviz2 right
Before this PR
With this PR
To reproduce the gifs see ros2/ros1_bridge#133 (comment)