|
1 | | -# Hector Controller Spawner - Multispawner – ROS2 Hardware & Controller Launcher |
| 1 | +# Hector Controller Spawner – **Multispawner** |
2 | 2 |
|
3 | | -Multi-spawner is a lightweight ROS2 node that boots an entire *ros2\_control* setup in a single shot. It resolves the tedium of juggling multiple **spawner** processes by batching most step: |
| 3 | +**ROS2 Hardware & Controller Launcher for `ros2_control`** |
4 | 4 |
|
5 | | -* **Wait‑for‑safety/Wait-for-Hardware:** Optionally blocks on an emergency‑stop (`std_msgs/Bool`) topic before doing anything. The motors may be impossible to activate while the e‑stop is engaged. |
6 | | -* **Hardware first:** Ensures every listed hardware interface is *loaded* **and** *active* (with automatic retries). |
7 | | -* **Smart loading:** Loads only the controllers that are missing (skips those already present). |
8 | | -* **Reduced overhead:** No per‑controller spawner nodes required, just one multispawner node. |
9 | | -* **Restarts after e-stop deactivation**: Restarts the hardware/controller setup after the e-stop is deactivated, if an e-stop topic is specified. |
| 5 | +**Multispawner** is a minimal ROS2 node that launches an entire `ros2_control` setup in a single coordinated pass. |
| 6 | +It robustly manages hardware interfaces and controllers, ensuring everything is loaded, activated (if required), and |
| 7 | +ready to go with minimal configuration. |
10 | 8 |
|
11 | 9 | --- |
12 | 10 |
|
13 | | -## Key Parameters |
| 11 | +## 🚀 Features |
| 12 | + |
| 13 | +* **Wait-for-safety (e-stop):** Optionally blocks on an `std_msgs/Bool` topic (e.g., emergency stop) before starting. |
| 14 | + Useful when motors can't be activated while safety is engaged. |
| 15 | +* **Re-activation:** Automatically reactivates hardware interfaces and controllers after releasing the e-stop (if they |
| 16 | + became inactive). |
| 17 | +* **Controller Manager Synchronization:** Waits for the controller manager to become available before proceeding. |
| 18 | +* **Hardware-first strategy:** Ensures all listed hardware interfaces are both *loaded* and *activated* (with automatic |
| 19 | + retries on failure). |
| 20 | +* **Intelligent controller loading:** Skips controllers already present - only loads and activates what’s missing. |
| 21 | +* **Automatic chaining:** Automatically detects and starts *chained controllers* together - no additional config |
| 22 | + required. |
| 23 | +* **Single-node simplicity:** No need to spawn one spawner per controller - Multispawner handles everything. |
| 24 | +* **Robust retry logic:** Retries failed hardware/controller activations with configurable delays. |
14 | 25 |
|
15 | | -| Name | Type | Default | Purpose | |
16 | | -|------------------------------------| ---------- | ------- |---------------------------------------------------------------------| |
17 | | -| `hardware_interfaces` | `string[]` | — | Ordered list of hardware interface names to activate. | |
18 | | -| `controllers` | `string[]` | — | Ordered list of controller names under management. | |
19 | | -| `<ctrl>.activate` | `bool` | `true` | Activate this controller after loading? | |
20 | | -| `<ctrl>.activate_as_group` | `string[]` | — | Controller groups that are activated togehter. | |
21 | | -| `retry_delay` | `double` | `5.0` | Seconds between retry attempts. | |
22 | | -| `estop_topic` | `string` | "" | Topic to wait on (false ⇒ proceed). Empty string disables the gate. | |
23 | | -| `restart_after_estop_deactivation` | `bool` | `true` | Restart hardware and controllers after e-stop deactivation | |
| 26 | +--- |
24 | 27 |
|
25 | | -See **athena.yaml** for a full example. |
| 28 | +## 🔧 Key Parameters |
| 29 | + |
| 30 | +| Name | Type | Default | Description | |
| 31 | +|-----------------------|------------|---------|---------------------------------------------------------------------------| |
| 32 | +| `hardware_interfaces` | `string[]` | - | Ordered list of hardware interface names to activate. | |
| 33 | +| `controllers` | `string[]` | - | Ordered list of controller names to load and manage. | |
| 34 | +| `<ctrl>.activate` | `bool` | `true` | Should the controller be activated after loading? | |
| 35 | +| `retry_delay` | `double` | `5.0` | Delay (in seconds) between retry attempts. | |
| 36 | +| `estop_topic` | `string` | `""` | Topic to wait on (false ⇒ proceed). Leave empty to disable e-stop gating. | |
| 37 | +| `restart_after_estop_deactivation` | `bool` | `true` | Restart hardware and controllers after e-stop deactivation | |
| 38 | +📄 See [`athena.yaml`](config/athena.yaml) for a complete configuration example. |
26 | 39 |
|
27 | 40 | --- |
28 | 41 |
|
29 | | -## Typical Usage |
| 42 | +## 🧪 Example Usage |
30 | 43 |
|
31 | 44 | ```bash |
32 | 45 | ros2 launch hector_controller_spawner hector_controller_spawner_launch.yml |
33 | 46 | ``` |
34 | | -Add it to a launch file exactly once—no per‑controller spawner nodes required. |
| 47 | + |
| 48 | +* Include **only once** in your launch setup. |
| 49 | +* No need for individual `spawner` calls per controller. |
0 commit comments