search

UniversalRobots / Universal_Robots_Client_Library

A C++ library for accessing the UR interfaces that facilitate the use of UR robotic manipulators by external applications.
Apache License 2.0
128 stars 98 forks source link

startup before booted robot does not work #94

Closed fmauch closed 2 years ago

fmauch commented 2 years ago

Starting up the client library interfaces before the robot is booted leads to multiple problems. This has been reported in the ROS driver, e.g. in https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/issues/272

Basically, we have to distinguish two cases:

If the robot is not connected / the IP address is configured wrong, opening a connection to the remote socket fails immediately here leading to this exception. Mitigating this would require having a retry mechanism either in the TCPSocket or inside the producer which would effectively block the startup process until a connection can be established.

When the robot is actually connected, but not fully booted, the connection described above works. The primary interface connection seems to be coming up and seems to be usable afterwards (did a quick test using the primary_interface example and a URSim docker container). The RTDE-Interface, however, seems to have more problems. As far as I know the RTDE-Interface on the robot side is restarted at some point. So, if we are too early, the restart either happens in the middle of the handshake (I had a test run, where the client was waiting for confirming the configured communication frequency) or it the handshake is performed, but then the client is waiting for new data which it will never get, as the restarted RTDE server never made a proper handshake with the driver. This would effectively require the RTDEClient to be able to go back to an uninitialized state either when no new data is received or when the handshaking process is not behaving as expected (timeouting at some point). In that case we want to restart the handshake automatically (with accepting that we might have to wait for an answer for an undefined time with the first handshake step).

I hope that helps someone implementing this, maybe @urmahp you want to have a go at this?

urmahp commented 2 years ago

I will be happy to try and implement this. However, I might not have time to look into this before Friday next week.

fmauch commented 2 years ago

fixed in #98