ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

The driver uses multiple connections to the robot controller, some of which are relatively high bandwidth (both RTDE and the "real-time" data broadcasts on tcp://:30003). Missed packets (due to noise on your link fi, or because of (temporarily) dropped connections) will interfere with the driver's correct functioning.

The ros_control approach used by the current implementation is thus not very well suited for lossy connections.

Overall, I would not recommend attempting to control an (industrial) robot controller in real-time over anything but a wired ethernet connection.

(note: this is not really specific to ur_robot_driver: I'm not aware of any real-time capable control interface for industrial robots which is suitable for use with a wireless connection)

I have script that controls UR5e using haptic device, it works perfectly connected directly using ethernet, but it doesn't work when i use 2 5G routers (arround 70ms ping).

The driver uses multiple connections to the robot controller, some of which are relatively high bandwidth (both RTDE and the "real-time" data broadcasts on tcp://:30003). Missed packets (due to noise on your link fi, or because of (temporarily) dropped connections) will interfere with the driver's correct functioning.

The Additionally, the ros_control approach used by the current implementation is thus not very well suited for lossy connections.connections. For e-Series controllers, a stable connection capable of supporting the 500 Hz control rate is essentially required. The 70 ms latency you quote is already multiple control periods of additional latency (on-top of the latency already present in the UR controller itself), which will further degrade control performance.

Overall, I would not recommend attempting to control an (industrial) robot controller in real-time over anything but a wired ethernet connection.

(note: this is not really specific to ur_robot_driver: I'm not aware of any real-time capable control interface for industrial robots which is suitable for use with a wireless connection)

I have script that controls UR5e using haptic device, it works perfectly connected directly using ethernet, but it doesn't work when i use 2 5G routers (arround 70ms ping).

The driver uses multiple connections to the robot controller, some of which are relatively high bandwidth (both RTDE and the "real-time" data broadcasts on tcp://:30003). Missed packets (due to noise on your link fi, or because of (temporarily) dropped connections) will interfere with the driver's correct functioning.

Additionally, the ros_control approach used by the current implementation is not very well suited for lossy connections. For e-Series controllers, a stable connection capable of supporting the 500 Hz control rate is essentially required. The 70 ms latency you quote is already multiple control periods of additional latency (on-top of the latency already present in the UR controller itself), which will further degrade control performance.

Overall, I would not recommend attempting to control an (industrial) robot controller in real-time over anything but a wired ethernet connection.

(note: this is not really specific to ur_robot_driver: I'm not aware of any real-time capable control interface for industrial robots which is suitable for use with a wireless connection)


Edit: seeing as 5G is mentioned: it may be possible to configure a dedicated connection with sufficient QoS parameters (at the "5G level", so not at the ROS topic level), but that would be out-of-scope of the driver. You'd have to look into getting that setup for your system.

I'd still personally be hesitant to use such a setup, but it may offer a way out.

I have script that controls UR5e using haptic device, it works perfectly connected directly using ethernet, but it doesn't work when i use 2 5G routers (arround 70ms ping).

The driver uses multiple connections to the robot controller, some of which are relatively high bandwidth (both RTDE and the "real-time" data broadcasts on tcp://:30003). Missed packets (due to noise on your link fi, or because of (temporarily) dropped connections) will interfere with the driver's correct functioning.

Additionally, the ros_control approach used by the current implementation is not very well suited for lossy connections. For e-Series controllers, a stable connection capable of supporting the 500 Hz control rate is essentially required. The 70 ms latency you quote is already multiple control periods of additional latency (on-top of the latency already present in the UR controller itself), which will further degrade control performance.

Overall, I would not recommend attempting to control an (industrial) robot controller in real-time over anything but a wired ethernet connection.

(note: this is not really specific to ur_robot_driver: I'm not aware of any real-time capable control interface for industrial robots which is suitable for use with a wireless connection)


Edit: seeing as 5G is mentioned: it may be possible to configure a dedicated connection with sufficient QoS parameters (at the "5G level", so not at the ROS topic level), but that would be out-of-scope of the driver. You'd have to look into getting that setup for your system.

I'd still personally be hesitant to use such a setup, but it may offer a way out.


Edit 2: your question reminded me of an open PR over at ros2/design which discusses mapping ROS 2 topic-level QoS to "unique network flows" for networks such as 5G infrastructures. See ros2/design#304.

While you're not using ROS 2, the authors of that design document may be interested in your use-case, and they may even be able to suggest approaches which could make whatever it is you're doing work.