reconnect the robot after connection dropped down.

[ZhengHaichao]

Hi Team,

A OEM customer is using this library in their product, a disconnection issue affects their development, so a method of reconnecting the robot is needed.

They are using the method in example/full_driver.cpp to create the connection, but when the connection dropped down, how to reconnect the robot in another thread? without closing their main program.

Thanks.

[fmauch]

If the connection is dropped, this is usually due to a non-realtime communication between the control pc and the robot controller. Our current suggestion is to use a real-time-patched kernel or at least a lowlatency kernel on the control pc side and a dedicated network connection (direct cable between the control pc and the robot controller, no switch).

We plan to release a version with options for a less restrictive communication requirements, but for now a stable and steady communication is required.

Depending on the use case you can also drop the requirements manually, by calling setKeepaliveCount(5) on the driver object, as recently updated in the example:

Universal_Robots_Client_Library/examples/full_driver.cpp

Lines 113 to 114 in 57c1a6a

	g_my_driver->setKeepaliveCount(5); // This is for example purposes only. This will make the example running more
	// reliable on non-realtime systems. Do not use this in productive applications.

However, this has the side effect that the robot will extrapolate on its own, when no updates from the pc side come in. So, when relying on setpoint streaming, this is not recommended.

[Kellen2021]

If the connection is dropped, this is usually due to a non-realtime communication between the control pc and the robot controller. Our current suggestion is to use a real-time-patched kernel or at least a lowlatency kernel on the control pc side and a dedicated network connection (direct cable between the control pc and the robot controller, no switch).

We plan to release a version with options for a less restrictive communication requirements, but for now a stable and steady communication is required.

Depending on the use case you can also drop the requirements manually, by calling setKeepaliveCount(5) on the driver object, as recently updated in the example:

Universal_Robots_Client_Library/examples/full_driver.cpp

Lines 113 to 114 in 57c1a6a

	g_my_driver->setKeepaliveCount(5); // This is for example purposes only. This will make the example running more
	// reliable on non-realtime systems. Do not use this in productive applications.

However, this has the side effect that the robot will extrapolate on its own, when no updates from the pc side come in. So, when relying on setpoint streaming, this is not recommended.

Hello, I have used this library in my software, but I am experiencing a remote connection disconnect issue. The specific error is as follows:
Failed to read from stream, reconnecting in 32 seconds....
Is it possible to achieve a reconnection without restarting the software using this library? I noticed that the DashboardClient class has connect and disconnect methods. Can reconnection for communication on other ports be achieved using a similar approach?

[fmauch]

Automatic re-connection is partly built-in and is on our schedule, but not at highest priority at the moment.