Support for booting UR-computer after ROS-driver

[jorgenfb]

I would like the driver to support waiting for the UR computer to boot up.

The driver will try to connect, but exit if unable to do so within a reasonable time. Since the ur_robot_driver is marked as required in the launch file the entire ROS system will be brought down with it.

I would like the driver to support waiting indefinitely for the robot to become available. This would allow us to instruct our users to turn on the robot if its not available. Todays solution just kills everything, including our user interface support systems.

I would like your opinion on this. Is this something you find useful and will consider supporting?

[fmauch]

The problem actually goes a bit deeper than that... If the driver gets started before the UR-controller is actually booted, things get bad as some subsystems are restarted again. As far as I remember, the RTDE handshake produced an exception, as it was restarted at some point during initialization. I don't remember it in detail, though.

And yes, that would definitely be nice to have, it was just never considered important enough to get ontop of the priority list. If you'd like to work on this, please let us know.

[jorgenfb]

I will spend some time working on this. For my use it is crucial that the whole ROS system is not brought down if the communication with the UR bot fails on boot.

I have tried digging into the details in the source. And the chain of initialization for the ur_hardware_interface is something along:

ur_hardware_interface -> ur_driver (with its socket connections) -> rtde_client

There are multiple potensial failures in that chain. Especially if trying to connect while the UR-machine is booting. I am hoping to not touch all of those areas and instead opt for just allowing the ur_hardware_interface node to die and restart to try again.

Allowing the ur_hardware_interface to die leads to issues with controllers starting to early. This seems to be solvable by having the control_manager wait until connection is established. The control_manager already has support for waiting until a std_msgs/Bool topic emits true. We could create this topic in the ur_hardware_interface to signal that the driver is ready. Adding this ready signal to the driver would also be useful in userland applications (like ours) to determine when the robot driver is good to go.

Proposal for the ready topic: Topic name: /ur_hardware_interface/ready Topic type: std_msgs/Book Topic behavior: Initially emit false until a message on both /ur_hardware_interface/robot_mode and /ur_hardware_interface/safety_mode has been emitted.

Does this sound like a feasible approach?

[fmauch]

In my opinion this seems like a workaround for some use cases, but not a proper solution.

You are right, that the problem is twofold:

• We need to make sure that the driver's connection is actually coming up correctly (RTDEClient needs to initialize properly)
• Controllers need to load and start before they timeout because the hardware_interface isn't started properly. However, I think, ROS control should be handling this better once we have a clean initialization, but I might be wrong there.

I would suggest to tackle the first problem first, as the hardware interface ideally shouldn't die at all. For this, we would have different scenarios:

• The robot isn't connected / reachable at all. Here, we could either die as we currently do or infinitely try to establish connections until we are successful. There is a mechanism for this built-in already, but I think it doesn't work on the first connection.
• The robot is currently booting. The machine is reachable, but connections to the sockets can't be established, as the ports aren't opened correctly, yet. This can lead to different things: First of all, the connections will wait for a certain timeout and then connect properly. However, the RTDE setup fails due to the problem mentioned earlier.

I wrote the above points out of my head, details might be wrong there and it might be worth it to investigate the current behavior in more detail to identify the different problems currently present.

Also, I suggest to wait until #266 is merged, so we can make the appropriate changes on the ur_client_library directly.

[aatb-ch]

I would also like to add support for this feature.

We have 2 UR10 in a museum running from a ROS machine, and currently have chosen to let everything run 24/7.

We would have prefered having the Remote ON and Program Autoload/Autostart on the controller being able to directly boot the robots, while powering up the ROS machine separately, but if the robot autostarts while the ROS ur_robot_driver node is not up yet, the program will quit, and if the ROS node starts before the robot is up it will crash. It would be really nice if both could independently start and connect when both are booted up, at which point polling for a ready message before sending trajectories feels much less brittle than pre-ROS custom boot scripts.

The "infinite respawn" sounds like a nice feature in this case.

[fmauch]

As a lot of this has to be fixed inside the client library, I've created a new issue there (https://github.com/UniversalRobots/Universal_Robots_Client_Library/issues/94) describing the points that would have to be addressed in my point of view.

[fmauch]

This issues should receive an update. The client library has been updated to support this, so we would now only have to adapt the driver. We had this working in the lab over the summer and as far as I remember, we only had to set the controller spawner wait times to infinity (Since we cannot activate the controllers without the hardware interfaces being ready). Just to mention, this was causing problems down the line, since other nodes (such as MoveIt!) were having their own timeouts while waiting for the controllers.

[github-actions[bot]]

This issue has not been updated for a long time. If no further updates are added, this will be closed automatically. Comment on the issue to prevent automatic closing.

[github-actions[bot]]

This issue has been closed due to inactivity. Feel free to comment or reopen if this is still relevant.