Open miguelprada opened 5 years ago
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:
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.
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:
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.
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"
ROSController
is run in the same thread asRTPublisher
, i.e. the consumer thread in theRTPacket
pipeline. It is generally considered a bad practice to use regular ROS publishers inros_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
userealtime_tools::RealTimePublisher
instead of plainROS::Publisher
s.