ROS publishers in "RT thread"

[miguelprada]

ROSController is run in the same thread as RTPublisher, i.e. the consumer thread in the RTPacket pipeline. It is generally considered a bad practice to use regular ROS publishers in ros_control's "RT thread", since publishing may be blocking in certain conditions. This should be more carefully examined.

A possible solution is to make RTPublisher use realtime_tools::RealTimePublisher instead of plain ROS::Publishers.

[gavanderhoorn]

This is definitely something that is worth a better look, but tbh ur_modern_driver in its current state is not deterministic at all anyway:

• use of STL (with default allocators)
• process doesn't request RT priority
• TCP sockets (although the UR controller requires this)

and some others.

It might make sense to refactor things such that there is a stand-alone ros_control node to mitigate the influence of some of these issues, but in the end the fact that TCP is used makes all of this a compromise anyway.

[miguelprada]

This is definitely something that is worth a better look, but tbh ur_modern_driver in its current state is not deterministic at all anyway:

• use of STL (with default allocators)
• process doesn't request RT priority
• TCP sockets (although the UR controller requires this)

and some others.

Some of them could be worked around:

• STL should be perfectly fine as long as sensibly used, e.g. no allocations outside initialization or inside RT thread in general (not that I've thoroughly checked that's the current situation)
• Requesting RT priority could be added (e.g. libfranka does it)

Others, such as TCP cannot.

It might make sense to refactor things such that there is a stand-alone ros_control node to mitigate the influence of some of these issues, but in the end the fact that TCP is used makes all of this a compromise anyway.

The standalone ros_control node crossed my mind more than once, although I'm not sure how much will it help performance-wise. In any case, I think we should try to improve the driver's determinism wherever is reasonable to; it doesn't make much sense to support ros_control otherwise.

And I would say this falls under such category. It's relatively straightforward to "fix" and can potentially improve performance.

[fmauch]

Another issue is that the publishers publishing one message per joint (e.g. the temperatures) don't publish all messages due to a configured queue size of one.

$ rostopic echo /joint_temperature | grep frame_id | head -n 30
  frame_id: "shoulder_link"
  frame_id: "wrist_3_link"
  frame_id: "shoulder_link"
  frame_id: "wrist_3_link"
  frame_id: "shoulder_link"
  frame_id: "forearm_link"
  frame_id: "wrist_1_link"
  frame_id: "wrist_3_link"
  frame_id: "shoulder_link"
  frame_id: "wrist_3_link"
  frame_id: "shoulder_link"
  frame_id: "wrist_3_link"
  frame_id: "shoulder_link"
  frame_id: "wrist_1_link"
  frame_id: "wrist_2_link"
  frame_id: "wrist_3_link"
  frame_id: "shoulder_link"
  frame_id: "wrist_3_link"
  frame_id: "shoulder_link"
  frame_id: "wrist_3_link"
  frame_id: "shoulder_link"
  frame_id: "wrist_3_link"
  frame_id: "shoulder_link"
  frame_id: "wrist_3_link"
  frame_id: "shoulder_link"
  frame_id: "wrist_3_link"
  frame_id: "shoulder_link"
  frame_id: "wrist_3_link"
  frame_id: "shoulder_link"
  frame_id: "upper_arm_link"