add spawner for hardware

[mamueluth]

Added a spawner for activation of the hardware, like the spawner for the controllers. This allows to wait for the hardware to be activated/configured (needed for my thesis on distributed control).

What has been done:

• create hardware_spawner for activation/configuration of hardware
• flags for activate/configure

Open questions:

• How to deprecate old way of activating the hardware, especially if neither configure_components_on_start nor activate_components_on_start flag is given.

---

Changes can be tested with this ros2_control_demo_repos

[destogl]

Great work!

I have only cosmetics to remark.

[destogl]

Open questions:

* How to deprecate old way of activating the hardware, especially if neither `configure_components_on_start` nor `activate_components_on_start` flag is given.

I think you managed this well. I would keep the warning as it is.

[arne48]

This appears to be a well executed addition of additional functionality.
I personally am totally fine with the usage of warnings for the users to make them aware of the change while preserving the original behavior in such cases.

[mamueluth]

Thanks for the quick review. Should all be done now.

[gavanderhoorn]

High-level comment: how does one spawn actual hardware?

From the description I believe I understand what this does, but in reality, the hw is already there.

Spawning is a rather overloaded word (perhaps in a ROS context), although in most cases it means to cause to exist, to produce or to cause to be created. The term hardware (as opposed to software) has a rather well defined meaning, and it doesn't appear this utility/cmdlet is capable of causing real hw to appear.

Would it be more accurate to say this initialises the components, forces them to (re)configure and then activates them (ie: manages their life-cycle)?

[destogl]

Would it be more accurate to say this initialises the components, forces them to (re)configure and then activates them (ie: manages their life-cycle)?

You are right. We took the nomenclature from the controller's side without much thinking. We use already initialize and (re)configure, that had in my head a bit different meaning. Should we call this "spawn_hardware_interface"?

The idea behind this functionality is to have a natively “tool changing” scenario. Long-term idea:

For example, you start your control stack without any hardware. (I know that it doesn't make much sense – but the idea is that the stack “always” lives – like when a hardware control box is turned on – but nothing further). Then you can initialize your robot, move it to the tool exchange station and then mechanically connect and then load a plugin (driver) for a tool and initialize it. And you are working like this for days. At some point, you need another tool, you place it to the tool-exchange station, reload your robot description with a new tool (kinematics, plugin, etc.) and then disconnect the old tool, connect the new one, load and work.

Does this make sense at all?

One of the issues we are trying to solve here is also to use robot description from the topic and make the control stack more resistant against hardware errors and hardware independent. This means that you could reload a whole driver for hardware without killing the control stack. This should help in multi-hardware systems to avoid crashing of everything if only one hardware driver has an issue. This is a bit different from in ros_control where HW and controller manager had 1:1 relationship.

[bmagyar]

Merging this now, please feel free to open a new PR to rename

[christophfroehlich]

Backport #1064 has conflicts because this one hasn't been backported. @destogl @bmagyar is there something to be said against backport this one?

[destogl]

@Mergifyio backport humble

[mergify]

backport humble

✅ Backports have been created

• #1216 add spawner for hardware (backport #941) has been created for branch humble but encountered conflicts

[destogl]

@Mergifyio backport iron

[mergify]

backport iron

✅ Backports have been created

• #1217 add spawner for hardware (backport #941) has been created for branch iron but encountered conflicts