What combination of platform is the ROS driver running on.
Docker
How did you install the UR ROS driver
Build the driver from source and using the UR Client Library from binary, Build both the ROS driver and UR Client Library from source
What robot platform are the driver connected to.
URSim in docker
Robot SW / URSim version(s)
5.13.1
How are you using the ROS driver
Headless without using the teach pendant
Issue details
Summery
If you set receive timeout for the dashboard client before calling connect, the receive timeout is reset within the connect function to 1 second. This means that the configured receive timeout has been reset to 1 second.
Issue details
The code that prevents from setting the receive timeout before connecting to the server can be found here. I suggest that the we add a check to see if the receive timeout has been set before resetting the timeout to 1 second.
Steps to Reproduce
The following code snippet will reproduce the issue.
#include <ur_client_library/ur/dashboard_client.h>
std::unique_ptr<DashboardClient> my_dashboard;
my_dashboard.reset(new DashboardClient(robot_ip));
timeval tv;
tv.tv_sec = 30;
tv.tv_usec = 0.0;
my_dashboard->setReceiveTimeout(tv);
if (!my_dashboard->connect())
{
URCL_LOG_ERROR("Could not connect to dashboard");
return 1;
}
my_dashboard->commandPowerOn()
When calling power on command the receive timeout will not be 30 seconds as expected instead it will 1 second.
Affected ROS Driver version(s)
1.3.2 client library
Used ROS distribution.
Other
What combination of platform is the ROS driver running on.
Docker
How did you install the UR ROS driver
Build the driver from source and using the UR Client Library from binary, Build both the ROS driver and UR Client Library from source
What robot platform are the driver connected to.
URSim in docker
Robot SW / URSim version(s)
5.13.1
How are you using the ROS driver
Headless without using the teach pendant
Issue details
Summery
If you set receive timeout for the dashboard client before calling connect, the receive timeout is reset within the connect function to 1 second. This means that the configured receive timeout has been reset to 1 second.
Issue details
The code that prevents from setting the receive timeout before connecting to the server can be found here. I suggest that the we add a check to see if the receive timeout has been set before resetting the timeout to 1 second.
Steps to Reproduce
The following code snippet will reproduce the issue.
When calling power on command the receive timeout will not be 30 seconds as expected instead it will 1 second.
Relevant log output
No response
Accept Public visibility