Refactor rclcpp::init to not take any arguments

[Jack-ReframeSystems]

On this line, Rclcpp init is called with a bunch of arguments: https://github.com/ros-controls/gz_ros2_control/blob/master/gz_ros2_control/src/gz_ros2_control_plugin.cpp#L338

This makes it hard to write other plugins for Gazebo that want to connect to ROS without being very specific in their load order. If I write another plugin and it calls Rclcpp init first, Gz Ros2 Control will not be able to initialize correctly.

I would like to refactor this method to set these parameters manually on the node instead of using rclcpp init to do it automatically. Is there any issues anyone sees with this approach?

[muttistefano]

I have been trying to set the parameters manually, but only those of the controller managers are feasible, I guess.
Being the controller manager spawned inside the gz plugin, I can set the correct parameters for each controller manager.
The problem arises when I spawn the controllers. I cannot set the controllers' parameters from this plugin, and I don't know how to set them In other ways.
If this cannot be done, the only solution might be multiprocessing(?), which I'm not very familiar with.
I will try to give this a thought and see if other methods exist.

[azeey]

Gazebo itself can now be run as a ROS node (see gazebosim/ros_gz#500) and calls rclpp::init itself before the GzRos2Control plugin, so calling rclcpp::init to set command line arguments will not work because it will not enter this if block:

gz_ros2_control/gz_ros2_control/src/gz_ros2_control_plugin.cpp

Lines 355 to 359 in e19b0ef

	if (!rclcpp::ok()) {
	rclcpp::init(
	static_cast<int>(argv.size()), argv.data(), rclcpp::InitOptions(),
	rclcpp::SignalHandlerOptions::None);
	}

Has there been any consideration to pass these arguments through rclcpp::NodeOptions instead as is done in rclcpp_components?

https://github.com/ros2/rclcpp/blob/2813045a96f721abdd0aafcdf32165180f72c0b1/rclcpp_components/src/component_manager.cpp#L165-L168