[ROS1] controller_stopper from ur_robot_driver repo

[fmauch]

Hi,

for the ROS1 ur_robot_driver we've created a small helper package and node called controller_stopper with the purpose of stopping controllers when the robot is not able to execute motions. (As in the case of UR: The program interpreting the commands sent to the robot is not running).

It basically listens to a boolean topic and stops all controllers instead of a set of preconfigured controllers when receiving a false message. On a true message it restarts the previously stopped controllers. This has the following benefits:

• When the interpreting program on the robot gets stopped, the JTC gets stopped and therefore the trajectory gets aborted this does
  • give the user feedback about the trajectory not being executed successfully
  • prevent the JTC from further interpolating and therefore leading to infeasible jumps / very fast motions once control is re-enabled
• While the robot is not ready to receive control commands, trajectories sent to the driver will get rejected (basically adding the same benefits as with the last point)

Obviously, this is a rather simple method to achieve that goal which has the culprit that nothing stops users from starting controllers manually while robot control is not active...

As we had implemented something similar for KUKA robots in the past, as well, we decided to write it with a more generic use in mind and to move it to a separate package, so it could be re-used by other hardware environments, as well.

Now, while finally doing a binary release of the ur_robot_driver for ROS1 the discussion came up, that the name was too generic to not have it inside the ros_control scope. So basically, there are two options: Either migrate this to ros_control or rename the package. Since renaming would probably go faster than opening discussions here, I'm currently tending to do that (although I'm currently struggling with finding a name that is both generic enough to encourage other developers to use it for their robot, bot not too generic either).

However, I wanted to raise the question here, whether there's an opinion from the ros_control maintainers' perspective. I'd be happy about any opinions or feedback regarding this so we can finally make our UR driver's binary release :-)

---

P.S.: I'd love to raise a discussion about ROS2 how we could do something similar e.g. using lifecycle management, but for this issue, that's probably out of scope. Basically, I think it would make sense to be able to stop writing controllers separately from read-only controllers...

[v4hn]

It would be great to have the package with ros_control in ROS.

@bmagyar any chance of migrating the package and releasing for noetic? We have at least two non-ur systems that do/want to use it.

[fmauch]

We've released the ur_robot_driver with the controller stopper included into the driver's package. This way, it would still be possible to release it as a standalone package in this repo.

[v4hn]

@fmauch the issue title should probably read controller_stopper ...

[fmauch]

@fmauch the issue title should probably read controller_stopper ...

oh my! Thanks for noticing!

[bmagyar]

Sounds like a decent addition to me. I think it could sit well within the controller_manager package even.

[fmauch]

I'll happily do a PR, then.