Autoconnect parameter
Feature summary
When the dashboard_client is started, it will try to automatically connect to the UR robot. If the robot is not connected yet or off, it will fail and exit. Would it be possible to let the user decide if autoconnect? I see that there are 2 services that can connect and disconnect the robot, so it would be possible to connect afterwards
The "problematic" line is this one: https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver/blob/e860145edb80a5cdf735631d7bd2561ed69621c5/ur_robot_driver/src/dashboard_client_ros.cpp#L61
Possible solution
Add a parameter to autoconnect and let the default true so that there is no behavior change:
node_->declare_parameter<bool>("autoconnect", true);
bool autoconnect = node_->get_parameter("autoconnect").as_bool();
if(autoconnect){
connect();
}
If implemented, would be great to backport it to Jazzy.
Thank you for your work!
Tasks
To complete this issue involves
- [ ] Implement the feature
- [ ] Make documentation
- [ ] Make Unit test
- [ ] Make example
- [ ] Test on real hardware
When the dashboard_client is started, it will try to automatically connect to the UR robot. If the robot is not connected yet or off, it will fail and exit.
It should automatically try to connect up to 10 times already.
Before attempting to connect to the dashboard server a connection to the primary interface will be established to query the robot's software version. There, the retry count of 10 is hard coded, but that could be made a parameter. Would that fit your proposal?
My question was more if it is possible to deactivate the autoconnect behavior by adding this parameter. The software could be launched and the robot could be connected trough the connect service call
As written earlier, before that the primary interface establishes a connection in order to query the robot's version. That would have to be taken into consideration, as well.
Ah sorry, I understand now.
Would it not be possible to query the version also in the connect() function?
The service call could return false if the version is wrong.
Otherwise increasing the number or retry is also a good option
That's what I meant with "would have to be taken into consideration, as well". It's definitively possible.