Move pub_rviz_markers_ to it's own callback queue #193

jspricke · 2021-08-02T15:08:34Z

waitForSubscriber used to call ros::spinOnce() which could trigger
callbacks from other topics in other threads. In case those have a lock
to only get called once, this would look the visual_tools thread.

Closes: #146

waitForSubscriber used to call ros::spinOnce() which could trigger callbacks from other topics in other threads. In case those have a lock to only get called once, this would look the visual_tools thread. Closes: PickNikRobotics#146

jspricke · 2021-08-02T15:10:10Z

You probably want the same here:

rviz_visual_tools/src/remote_control.cpp

Line 160 in 240b6ec

ros::spinOnce();

not sure.

jspricke · 2021-08-02T15:26:17Z

This is an ABI break, btw.

AndyZe · 2021-08-02T16:53:09Z

src/rviz_visual_tools.cpp

@@ -280,7 +280,9 @@ void RvizVisualTools::loadMarkerPub(bool wait_for_subscriber, bool latched)
  }

  // Rviz marker publisher
-  pub_rviz_markers_ = nh_.advertise<visualization_msgs::MarkerArray>(marker_topic_, 10, latched);
+  ros::NodeHandle nh(nh_.getNamespace());
+  nh.setCallbackQueue(&vis_marker_queue_);


A comment on why this is being done would be great

AndyZe · 2021-08-02T16:56:38Z

src/rviz_visual_tools.cpp

@@ -334,7 +336,7 @@ bool RvizVisualTools::waitForSubscriber(const ros::Publisher& pub, double wait_t
                                                  "will be lost.");
      return false;
    }
-    ros::spinOnce();
+    vis_marker_queue_.callAvailable(ros::WallDuration());


Your change looks good. It makes sense to me.

But, did you try deleting ros::spinOnce() completely? There might not be any noticeable downside and that is the simpler fix.

Well the code tries to block until there is a subscriber so deleting it would result in a different behavior.
But I just bumped into this again when using ros::spin() and there PR didn't help so I think it would be better to drop this or provide a non blocking interface. I can come up with a patch if more people agree.

I added this function because often important stuff was published to Rviz before Rviz was done loading, and the visualizations would not work correctly. It was great for demo / testing code, not sure its useful in a production env though. Maybe just warn API users not to use this function in production systems

but is there a way to make it work without calling this function? I guess one could take the markers_ and do the publish manually but that sounds wrong, or set pub_rviz_markers_connected_ and pub_rviz_markers_waited_ to true..
Maybe we could add a variable to the constructor to disable the connection check or have a trigger variant to not do it. Honestly I think the check should be disabled by default. What do you think?

I just verified in a small C++ test script that spinning is fully independent of node connection handling and I would have been surprised by anything else.
So even if you don't spin, getNumSubscribers reports new subscribers as well.

@jspricke From all that I can see the change in behavior you refer to actually means fixing the bug.
The method is not supposed to spin any queue. It's supposed to wait and poll*.

-- Slightly off-topic

I was convinced there is an API somewhere to get notified about new subscribes/unsubscribes and that would be even better. But I can't seem to find it

davetcoleman · 2021-08-04T19:42:04Z

src/rviz_visual_tools.cpp

@@ -280,7 +280,9 @@ void RvizVisualTools::loadMarkerPub(bool wait_for_subscriber, bool latched)
  }

  // Rviz marker publisher
-  pub_rviz_markers_ = nh_.advertise<visualization_msgs::MarkerArray>(marker_topic_, 10, latched);
+  ros::NodeHandle nh(nh_.getNamespace());


can you make this nh var name more descriptive, so its clear how its diff than nh_?

davetcoleman · 2021-08-04T19:44:14Z

src/rviz_visual_tools.cpp

@@ -334,7 +336,7 @@ bool RvizVisualTools::waitForSubscriber(const ros::Publisher& pub, double wait_t
                                                  "will be lost.");
      return false;
    }
-    ros::spinOnce();
+    vis_marker_queue_.callAvailable(ros::WallDuration());


I added this function because often important stuff was published to Rviz before Rviz was done loading, and the visualizations would not work correctly. It was great for demo / testing code, not sure its useful in a production env though. Maybe just warn API users not to use this function in production systems

v4hn

This is the alternative approach to #224 . They solve the same problem in different classes.
I believe either approach is fine and these issues should be fixed upstream.

@tylerjw got a minute?

codecov · 2022-09-27T07:55:52Z

Codecov Report

❗ No coverage uploaded for pull request base (master@99e8c9c). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #193   +/-   ##
=========================================
  Coverage          ?   19.78%           
=========================================
  Files             ?        5           
  Lines             ?     1703           
  Branches          ?        0           
=========================================
  Hits              ?      337           
  Misses            ?     1366           
  Partials          ?        0

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

JafarAbdi

LGTM, I like the AsyncSpinner approach more, though :D

JafarAbdi · 2022-10-05T13:21:14Z

After 13 months 😿

Move pub_rviz_markers_ to it's own callback queue

e1dc521

waitForSubscriber used to call ros::spinOnce() which could trigger callbacks from other topics in other threads. In case those have a lock to only get called once, this would look the visual_tools thread. Closes: PickNikRobotics#146

AndyZe reviewed Aug 3, 2021

View reviewed changes

davetcoleman reviewed Aug 4, 2021

View reviewed changes

v4hn approved these changes Aug 25, 2022

View reviewed changes

v4hn mentioned this pull request Aug 25, 2022

spin independent thread for RemoteControl #224

Merged

jspricke closed this Sep 26, 2022

jspricke deleted the fix_deadlock branch September 26, 2022 11:49

jspricke restored the fix_deadlock branch September 27, 2022 07:49

jspricke reopened this Sep 27, 2022

JafarAbdi approved these changes Oct 5, 2022

View reviewed changes

JafarAbdi merged commit 74b92d8 into PickNikRobotics:master Oct 5, 2022

jspricke deleted the fix_deadlock branch October 5, 2022 16:02

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Move pub_rviz_markers_ to it's own callback queue #193

Move pub_rviz_markers_ to it's own callback queue #193

jspricke commented Aug 2, 2021

jspricke commented Aug 2, 2021

jspricke commented Aug 2, 2021

AndyZe Aug 2, 2021

AndyZe Aug 2, 2021

jspricke Aug 3, 2021

davetcoleman Aug 4, 2021

jspricke Aug 4, 2021

v4hn Aug 11, 2021

davetcoleman Aug 4, 2021

davetcoleman Aug 4, 2021

v4hn left a comment

codecov bot commented Sep 27, 2022

JafarAbdi left a comment

JafarAbdi commented Oct 5, 2022

Move pub_rviz_markers_ to it's own callback queue #193

Move pub_rviz_markers_ to it's own callback queue #193

Conversation

jspricke commented Aug 2, 2021

jspricke commented Aug 2, 2021

jspricke commented Aug 2, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

v4hn left a comment

Choose a reason for hiding this comment

codecov bot commented Sep 27, 2022

Codecov Report

JafarAbdi left a comment

Choose a reason for hiding this comment

JafarAbdi commented Oct 5, 2022