robotiq_control.launch.py: spawners retry forever after ros2_control_node exits

[ebarnett3]

When ros2_control_node exits — for example when no gripper is attached and on_configure fails — the three spawners launched by robotiq_control.launch.py keep polling /controller_manager/list_controllers indefinitely instead of shutting down with the rest of the launch. The user has to Ctrl-C the whole launch, and until they do the processes stay up and spam the logs.

The connection failure itself is now reported cleanly (an actionable message naming 24 V power, RS-485 wiring, com_port / slave_address / baudrate), so what remains is the launch never terminating.

Reproduce

Bring up with no gripper attached:

ros2 launch robotiq_description robotiq_control.launch.py com_port:=/dev/ttyUSB0

Observed

[spawner-3] [INFO] [spawner_joint_state_broadcaster]:
  waiting for service /controller_manager/list_controllers to become available...
[spawner-4] [WARN] [spawner_robotiq_gripper_controller]:
  Could not contact service /controller_manager/list_controllers
[spawner-5] [WARN] [spawner_robotiq_activation_controller]:
  Could not contact service /controller_manager/list_controllers
... repeating every ~10 s, indefinitely

Analysis

• The launch file declares no on_exit action tying the spawners' lifetime to ros2_control_node.
• controller_manager/spawner loops by default with no absolute timeout — only a periodic retry with a log line.

Possible fixes

1. In the launch file: register an event handler on OnProcessExit(ros2_control_node) that emits a Shutdown event. A dozen lines of Python, local to this repo.
2. Upstream in ros2_control: give spawner a --max-retries / --max-wait-time that makes it bail after N attempts. Cleaner conceptually, but needs an upstream PR.

Option 1 is enough to make a failed bringup exit cleanly; option 2 would be a community contribution on top.