multiple GazeboSimROS2ControlPlugin

[muttistefano]

Hi all,
i have been trying to use multiple GazeboSimROS2ControlPlugin , spawning different robots in Gazebo.

I noticed that only the first controller manager spawned has the correct parameters, while the successive ones have gibberish parameters or nothing.
Checking the implementation of the gz control plugin, i could verify that the "--ros-args --params-file FILENAME" string is generated correctly for all the different plugins.
Where could the problem be ?
Thanks

[Jack-ReframeSystems]

You might be hitting the same problem that I want to fix with this ticket: #166

GazeboSimROS2Control is initialized by creating its arguments internally and then setting the context to use them. If the context is already initialized then it doesn't set the arguments.

Since the context in RCL is per process, the second controller can't set its arguments properly, so who knows what kind of undefined behavior that causes. I was having the same issue when my other ROS-using plugins launched prior to gz_ros2_control.

[muttistefano]

Hi @Jack-ReframeSystems , thanks for the info.
So, just to recap. Gezebo runs both plugins in a single process, so rclcpp::init(args...) has an undefined behaviour the second time it gets called.
It might not be a straightforward fix.

[johnny555]

Thanks for this issue, I've had the same problem with the second controller_manager not reading its parameters file.

I.e. Robot A, using gz_ros2_control to spawn its controllers, then Robot B in the same simulation also calling its own instance of gz_ros2_control. The controller manager associated with Robot B would not read in its parameters, so none of its controllers could be activated.

The dodgy work around was to put all the config for Robot B in Robot A's config file, this way it also gets loaded into the context. When Robot B spawns its controllers have the parameters they need to start.

Obviously now I need to always spawn robot A before robot B, which is kinda annoying, but atleast I have controllers working! Yay!

[muttistefano]

Hi @johnny555,
Thanks for the info!
Very clever solution :)

[solid-sinusoid]

This certainly looks like a hack on the system. I'm also trying to resolve this issue locally, but I'm still unsuccessful. I am little familiar with the implementation that exists in gazebo_ros2_control, but it seems to me that there are no problems with it.

Unfortunately, it’s important for me to use different files for different controller_managers with different namespaces because they are generated automatically using RewrittenYaml and this is convenient

[tchoopojcharoen]

Thanks for this issue, I've had the same problem with the second controller_manager not reading its parameters file.

I.e. Robot A, using gz_ros2_control to spawn its controllers, then Robot B in the same simulation also calling its own instance of gz_ros2_control. The controller manager associated with Robot B would not read in its parameters, so none of its controllers could be activated.

The dodgy work around was to put all the config for Robot B in Robot A's config file, this way it also gets loaded into the context. When Robot B spawns its controllers have the parameters they need to start.

Obviously now I need to always spawn robot A before robot B, which is kinda annoying, but atleast I have controllers working! Yay!

Does this mean the entire simulation will have only one controller_manager or will it be multiple controller_managers under different namespace loading the same parameter file, which has parameters of each namespaces inside ?

[krrish-jindal]

any update on this I want to load 2 different bot with different namespaces