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

Use dedicated TransformListener thread #551

Merged
merged 1 commit into from
Jun 17, 2020

Conversation

ymd-stella
Copy link
Contributor

Fixes #359.
Problem detail is #359 (comment).

@mikeferguson
Copy link
Contributor

+1. This seems to make everything a lot smoother in RVIZ2 (for instance, when a robot arm is moving, it's very jerky without this patch).

*buffer_, rviz_ros_node.lock()->get_raw_node(), false);
if (using_dedicated_thread) {
tf_listener_ = std::make_shared<tf2_ros::TransformListener>(
*buffer_, true);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will actually create a new node, did you try what happens if you just use std::make_shared<tf2_ros::TransformListener>( *buffer_, rviz_ros_node.lock()->get_raw_node(), true); - shouldn't this already spin the TransformListener in a dedicated thread?

Copy link
Contributor Author

@ymd-stella ymd-stella Jun 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@Martin-Idel Martin-Idel Jun 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I see... So the correct way to solve this should be to actually make RViz multi-threaded and spin the transformer callback in its own thread then (and more often than e.g. the update loop).

I guess this is a much more subtle undertaking, so I would propose:

Copy link
Contributor Author

@ymd-stella ymd-stella Jun 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a "todo" comment that this actually introduces a new node and should be done via threading,

If you provide the concrete comment, I'll add them to this PR. (I don't know the format of the TODO comments on this project.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No real schema except for linters. The following should do (you can also add your name, but I find the naming inconsistent, it's just enforced by cpplint)

TODO(anyone): The TransformListener needs very quick spinning so it uses its own node here. Remove this in favor of a multithreaded spinner and ensure that the listener callback queue does not fill up.

You'll probably need to split it up into multiple lines.

@jacobperron The error analysis seems sound and the solution works on several machines. When this got ported we explicitly avoided making new nodes if possible, but making RViz multithreaded requires much more work, since this is an issue many people complained about, I think this is a good compromise - unless @ymd-stella wants to jump in and do this of course.
Maybe you could take a quick look?

Copy link
Member

@jacobperron jacobperron Jun 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that a multithreaded executor sounds like the best way to go. I'm okay with merging this workaround in the meantime with a TODO as you suggest.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added the comment. I've written TODO(pull/551) to make it easier for those who found it to look up the details.

@ymd-stella ymd-stella force-pushed the use-dedicated-tf-listener-thread branch from bd03113 to f0442de Compare June 16, 2020 00:57
Signed-off-by: ymd-stella <world.applepie@gmail.com>
@ymd-stella ymd-stella force-pushed the use-dedicated-tf-listener-thread branch from f0442de to f528bfd Compare June 17, 2020 14:39
@jacobperron
Copy link
Member

jacobperron commented Jun 17, 2020

The Rpr_* job is failing for an unrelated reason.

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS Build Status (unrelated warning)
  • Windows Build Status (unrelated warnings, already fixed on ros2 I believe)

Copy link
Member

@jacobperron jacobperron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ymd-stella Thanks for the investigation and the patch!

@jacobperron jacobperron merged commit 0ba40ae into ros2:ros2 Jun 17, 2020
wjwwood added a commit that referenced this pull request Jun 23, 2020
* restore compatibility with older Qt versions (#561)

Signed-off-by: Dirk Thomas <dirk-thomas@users.noreply.github.com>

* Suppress warnings when building with older Qt versions. (#562)

Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>

* Don't try to moc generate env_config.hpp file. (#550)

This removes one more warning from rviz_common builds.

Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>

* rewrite hack to avoid CMake warning with assimp 5.0.1 and older, apply cross platform (#565)

Signed-off-by: Dirk Thomas <dirk-thomas@users.noreply.github.com>

* Use dedicated TransformListener thread (#551)

Signed-off-by: ymd-stella <world.applepie@gmail.com>

* restore alphabetical include order (#563)

Signed-off-by: Karsten Knese <karsten@openrobotics.org>

* Don't install test header files in rviz_rendering. (#564)

* Don't install test header files in rviz_rendering.

This change started as a relatively simple try at not installing
test includes when installing rviz_rendering.  As you can see,
it ballooned into quite a large change, so here is an explanation
of why.

We shouldn't install test include header files when installing
the package; that just ends up on the end user system, and
is a non-supported API.  Worse, we don't want to compile test
code in our main library.  Yet rviz_rendering is currently doing
both of these things.

Unfortunately, it is somewhat tricky to make that code and header
file private.  The problem is that that test code is used in
rviz_rendering, rviz_common, rviz_default_plugins, and
rviz_rendering_tests.

One solution might be to extract that test code into its own
package, and then have all of the other packages depend on it.
The problem is that that test package would both be depended
on by rviz_rendering (for tests), and depends itself on rviz_rendering
(for its functionality), creating a dependency loop.

The solution I opted for here is to copy the test code into the
appropriate packages.  This leads to some duplication of functionality,
but it effectively breaks the dependency loop and succeeds in
eliminating the test code from our installed library.

Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>

Co-authored-by: Dirk Thomas <dirk-thomas@users.noreply.github.com>
Co-authored-by: Chris Lalancette <clalancette@openrobotics.org>
Co-authored-by: ymd-stella <7959916+ymd-stella@users.noreply.github.com>
Co-authored-by: Karsten Knese <Karsten1987@users.noreply.github.com>
jacobperron pushed a commit that referenced this pull request Jul 20, 2020
Signed-off-by: ymd-stella <world.applepie@gmail.com>
jacobperron pushed a commit that referenced this pull request Jul 20, 2020
Signed-off-by: ymd-stella <world.applepie@gmail.com>
jacobperron added a commit that referenced this pull request Oct 26, 2020
Signed-off-by: ymd-stella <world.applepie@gmail.com>

Co-authored-by: ymd-stella <7959916+ymd-stella@users.noreply.github.com>
jacobperron added a commit that referenced this pull request Oct 27, 2020
Signed-off-by: ymd-stella <world.applepie@gmail.com>

Co-authored-by: ymd-stella <7959916+ymd-stella@users.noreply.github.com>
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

Successfully merging this pull request may close these issues.

High latency in TF propagation
4 participants