Add launch argument to optionally omit the controller_stopper node

[eholum]

Adds an argument to ur_control.launch.py to optionally launch the controller_stopper node.

In our hardware setup we have multiple types of robots (URs, rails, lifts, AMRs, etc), and have implemented some custom software e-stops for halting everything in the system, then restarting controllers as needed. While we normally rely on the controller_stopper, we've found that it steps on the toes of our custom e-stopper. It would be handy to optionally not include the node in a way that lets us continue to use the driver's launch files as is.

I don't imagine this change will be something that most UR users will need. That said, it may be a nice to have if anyone runs into a similar situation as we are.

Testable with variations of:

ros2 launch ur_robot_driver ur5e.launch.py robot_ip:=0.0.0.0 use_mock_hardware:=false use_controller_stopper:=false

[eholum]

Suggested change

	"force_torque_sensoqr_broadcaster",
	"force_torque_sensor_broadcaster",

[urfeex]

I would actually rather not have this. The controller_stopper is an essential piece in a) avoiding sudden motions of the robot in case the user has sent a target while the robot program was not running and b) help making clear that the robot currently cannot accept new targets since the controller is not running.

What is your reasoning why you would not to have it running? Anyway, users can still build their own launchfiles without the controller stopper if they really want to. That obviously requires a bit more understanding than just running a launch file, but disabling the controller stopper also requires understanding what its purpose is and what I as a user have to take care of myself.

[eholum]

Thanks for the quick feedback, @urfeex! That makes complete sense to me, we'll stick with building our own launch files.

We run into issues when using applications that don't necessary reset their controller commands after something is paused. For example, MoveIt Servo may continue sending commands to a JTC even after the JTC is stopped by the controller stopper. When the UR is reset and the controller reactivated there will be a resulting joint jump.

We have similar situations with other types of hardware where the application or controller needs to be reset before a controller is re-activated, so to handle that we've rolled everything into a software e-stop. What we want on top of that is a snapshot of the controller manager's state prior to triggering a stop, which we might not be able to get if the UR's controller stopper triggers before our node's does.

In any case, thanks for the information. If this option were there I think it would be more trivial for a novice user to do something dangerous, whereas it's a much more deliberate choice on our end.

Closing this.