Configurable reconnection timeout and attempts for RTDE client

[domire8]

Feature summary

Short introduction to the feature and why it should be implemented
The current reconnection timeout and attempts for RTDE client objects are currently hardcoded to 10s and 10 attempts here. It would be nice to be able to configure these.

Followed by a longer description
The consequence of the current implementation is that the init of RTDE clients cannot be terminated earlier than 100 seconds in the worst case (10 attempts with 10s sleep in between). Since the timeout really is hardcoded and the number of attempts is a const variable, there is no way to configure this behavior. It would be neat to be at least able to set the number of attempts, potentially using ifdef / ifndef directives, or constructor arguments.

Additional detail: In the current implementation, the thread even sleeps after the last attempt has been made, I believe it should only sleep if the number of attempts hasn't reached the max yet.

Happy to help out if desired.

Related issues

Tasks

To complete this issue involves

• Implement the feature
• Make documentation
• Make Unit test
• Make example
• Test on real hardware

[urfeex]

Thank you for reporting that!

Actually, this retention method will only be the second line of action. The output you see is coming from inside setupCommunication(max_num_tries, reconnection_time); which is defined through parameters of the init() method.

If that is parameterized in a way that it will do a finite number of checks, it will throw an exception, so the outer check in the RTDE client will never be triggered.

This could definitively be improved, though. Having one check should be enough.

Nonetheless, sleeping after the last fail seems absolutely unnecessary, that's right!

[domire8]

Ah yes good point I didn't see that, I only saw that I would get 10 times the log from line 91 every 10seconds.

My request is still valid though because the UR driver class calls the init() without arguments.

[urfeex]

Yes, I did not want to say that your request isn't reasonable. May I ask, why this is a particular problem?

The consequence of the current implementation is that the init of RTDE clients cannot be terminated earlier than 100 seconds

It should still be possible to terminate an initializing RTDEClient e.g. by pressing CTRL-C when starting the application. Again, I'm not saying your request is invalid, I would like to better understand what issue exactly needs to be resolved here.

Using ifdef / endif isn't that favorable in my opinion and adding more constructor arguments to UrDriver is also something I would not like to do that much. We did that in the past and that left us with 4 different constructors at the moment that have quite long argument lists already.

A possible way to make this possible would be to have some kind of configuration / parameter structure to the UrDriver object but that would require some more refactoring. We'd have to discuss that internally, first.

[domire8]

We did that in the past and that left us with 4 different constructors at the moment that have quite long argument lists already.

Agree with that point.

It should still be possible to terminate an initializing RTDEClient e.g. by pressing CTRL-C when starting the application

Indeed, although within our framework, a user is not in power of pressing CTRL-C. We dynamically create and remove resource managers and controller managers, and there is programmatically no pretty solution for destroying an object that is currently in a blocking loop for connecting the RTDE client. Hence my motivation to configure how long it should be blocking for.

Thanks for the answers!

[urfeex]

Would changing that locally and compile the client library from source work for you as a workaround until we have sorted that out cleanly? Or is that blocking you hard at the moment?

[domire8]

Absolutely, if you foresee internal discussions, we will happily do that.

[urfeex]

We have discussed going for a configuration struct for the UrDriver. Starting from that adding a parameter for the reconnection timeout / #attempts should be easy. I'll notify this issue once we have a PR for the config struct in place.

[domire8]

very cool, thanks!

[domire8]

Thanks for implementing in #266!