[ROS1] controller_stopper from ur_robot_driver repo #510
Description
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...