Serial port communication errors through ROS driver

ROS
1

Hello there,

We are testing the tool serial port communication through the ROS driver but we are facing several communication errors.
We are wondering it the serial communication has a baud rate upper limit which is smaller than the 5Mbaud provided on the robot interface (our device communicates with 2Mbaud rate).

The following command gets the same parameters used for our URCap:

roslaunch ur_robot_driver ur5e_bringup.launch use_tool_communication:=true tool_voltage:=24 tool_parity:=0 tool_baud_rate:=2000000 tool_stop_bits:=1 tool_rx_idle_chars:=1.5 tool_tx_idle_chars:=3.5 tool_device_name:=/dev/ttyUSB0 robot_ip:=ur5e

Have you tested it up to 2Mbaud?

Thank you for your assistance,
Alessandro Tondo @qbrobotics

2

From a driver development perspective I can add that we never tested such high baud rates.

You could start investigating this by having a look at your network traffic. Also, you can try launching the tool communication without the driver running:

rosrun ur_robot_driver tool_communication _voltage:=24 _parity:=0 _baud_rate:=2000000 _stop_bits:=1 _rx_idle_chars:=1.5 _tx_idle_chars:=3.5 _device_name:=/dev/ttyUSB0 _robot_ip:=ur5e
1 Like
3

Thank you for your prompt reply.
I’ll back to you as soon as possible with more details.

4

@mauch do I need to run the externalControl node on the robot before the rosrun?
Because if I do not start the driver I get socket.error: [Errno 111] Connection refused.
And to run the externalControl I need to launch the whole driver, isn’t it?

Thank you for you assistance.

5

Ah, it’s been too long, I’ve written that script…

Without running ExternalControl and the driver, you’ll need to manually activate tool communication on the robot in Installation->General->Tool and set the tool voltage in IO->Tool Output

Usually, this gets setup by the driver as part of the URScript running inside the program.

Then, to start the ROS side, do

rosrun ur_robot_driver tool_communication  _device_name:=/dev/ttyUSB0 _robot_ip:=ur5e

Sorry for the confusion.

1 Like
6

Thank you @mauch, now it starts correctly.
We have tried the 2M baud communication, but the initial error persists even without the whole driver loaded.

We are going to try the communication with a lower baud rate and see if it works (e.g. using at least at 460k baud).
I’ll let you know as soon as possible.

7

But then, the network data rate can’t be the bottleneck here…

There could be latency effects, however, resulting from the underlying tcp stack. We’re not using anything fancy here, currently.

8

Don’t you think that things will change with a smaller baud rate?

Maybe UDP instead of TCP could lead to better results?
But I believe that it is not a choice in this case.

9

Sure, a smaller baud rate might help, but I think, (from a transfer rate perspective) 2MBaud should work, as well.