class gz_ros2_control/GazeboSimSystem with base class type hardware_interface::SystemInterface does not exist

[wltjr]

I am trying to get proper integration between ROS 2 and Gazebo, I believe newer gazebo, as Gazebo Classic 11.x uses gazebo_ros2_control But with either, I keep having an issue trying to not use fake_components/GenericSystem or mock_components/GenericSystem, and my hardware interface of robot_hardware_interface/RobotSystemHardware. The full error is

[ros2_control_node-1] [INFO] [1707853400.514734049] [resource_manager]: Loading hardware 'ros2_control'
[ros2_control_node-1] terminate called after throwing an instance of 'pluginlib::LibraryLoadException'
[ros2_control_node-1]   what():  According to the loaded plugin descriptions the class gz_ros2_control/GazeboSimSystem with base class type hardware_interface::SystemInterface does not exist. Declared types are  fake_components/GenericSystem mock_components/GenericSystem robot_hardware_interface/RobotSystemHardware

I opened this issue on my repo for the older one, which I am trying to move away from again.

I am unsure the proper way to go about configuring all this. I have a way to start my actual hardware with a sim flag, but I have another launcher for gazebo, I launch rviz2 directly. The main issue is with the plugin. I do not know if I should start a ros2 controller_manager or not. It seems like Gazbo provides that, but I cannot get ros2_control to properly load either plugins, they have the same issue. I even tried to compile the sources here directly from master/head, and same issue.

It seems like the signature or something does not match as its never listed in the available declared types, and I am forced to use only one of the declared types listed.

ros-iron-controller-manager/jammy,now 3.23.0-1jammy.20240208.072444 amd64
ros-iron-gz-ros2-control/jammy,now 1.1.4-2jammy.20240208.073405 amd64
ros-iron-ros2-controllers/jammy,now 3.21.0-1jammy.20240208.073933 amd64

[wltjr]

This very well might be a usage issue. I am able to use use gz_ros2_control if I start things different for gazebo, not using ros2 controller manager. However, that does not work for RViz2, while I can control the robot in Gazebo, nothing happens in RViz. If I start with mock hardware using controller manager, then I can control the robot in RViz, but not in Gazebo. I haven't achieved ability to run Rviz2 and Gazebo, with both responding to the same commands, from custom teleop joy, but also is the same when using the teleop_joy_keyboard, its Gazebo or Rviz2 never both.

I presently have 2 different launch files, and I had to add a lot of conditionals to my ros2_control structure for URDF.
Mock Hardware for Rviz2 and then the one for simulated hardware in Gazebo. I am presently using classic, as it does not respond to controls at all using the newer Gazebo that use this project/repo.

[wltjr]

I got this going but its pretty wonky, I am not really using things via ros2_control, though gz_ros_control seems to be controlling some stuff per gz_ros_control.txt but my graph is disconnected, and I have to have a whole separate section for diff drive plugin which duplicates the settings from the ros2_control configuration file. I also had to use the ros_gz_bridge to map various things from Gazebo to ROS for RViz2 and other.

I am able to control and do everything in Gazebo 6 Fortress, robot drives, I can control position and velocity controlled joints via teleop_manual_joy, the interface I wrote for those, but it does not seem to be going through ros2_control nor through gz_ros_control, but through other mappings of topics and bridge. I am pretty sure that graph shows the problem, many things not connected, not part of the graph. If I shut down the teleop_manual_joy even more is disconnected from graph.

[jasmeet0915]

Hi @wltjr, I was facing the same issue while working on my project when I found that the issue occurred because of 2 controller_manager nodes being spawned: One from gz_ros2_control and one from my launch file. Going through the repo you linked, I think it might be the same case for you. You could verify this by using ros2 node list. If you do see 2 controller_manager nodes, I would recommend you to remove it from you launch file.

[wltjr]

@jasmeet0915 thank you for your response. I have no other way to start things like diff_drive_controller, position, or velocity ones, which I seem to need even when using Gazebo or those parts don't work in Gazebo unless I use a controller manager, but not via ros2_control_node. Though it is not as you describe I do not think, I only have one.

root@ws:/# ros2 node list
/autonomy
/controller_manager
/diff_drive_controller
/gz_ros_control
/joint_state_broadcaster
/position_controllers
/robot_state_publisher
/ros_gz_bridge
/ros_gz_image
/slam_toolbox
/static_transform_publisher_2QN8rVmWYt5DWmdx
/static_transform_publisher_AHe8YRYnXKdSJGQz
/static_transform_publisher_Df6wuz1htcmhG7UU
/transform_listener_impl_55f6b9f8ac80

But I also have to configure many things twice, like the one spawned from gz_ros_control it does not read the ros2 control yaml configuration file, I have to have that else where, and I am duplicating settings it should read from configuration.

Things work, but my graph is disconnected, so I know something is not right. See how in my graph both are disconnected, and if I don't start either, things do not work. I cannot even start the general controller manager on its own per the initial reported issues. I have never seen most things under gz_ros_control, I can try again with how I am starting things, but I don't think there is another way. This is my launch file for gazebo .

I just feel like I should be able to put gz_ros2_control/GazeboSimSystem into the ros2 control plugin xml, and it load things like it does for normal hardware drivers and others, and from there Gazebo would load its diff_drive_plugin or other needed.

Thanks for your info, I haven't found any definitive sources on how to start various stuff in a way it can be used for hardware and simulation. At some point I want to merge in my gazebo and hardware launch files, which I can do now, but I use the ros2_control_node which I cannot with Gazebo.

[christophfroehlich]

Thanks for your info, I haven't found any definitive sources on how to start various stuff in a way it can be used for hardware and simulation. At some point I want to merge in my gazebo and hardware launch files, which I can do now, but I use the ros2_control_node which I cannot with Gazebo.

Does example_9 help you? There is a URDF where you can switch between gazebo and a custom hardware component (like your hardware would be).

[wltjr]

Yes, that is what I am doing now, I have a variable that controls which plugin to use with ros2_control. That is fine, but the main issue is having settings for the gazebo plugin, like the diff drive controller, that is duplicated in xml from yaml.

I cannot use ros2_control_node to start components for Gazebo as I would with actual hardware, even Example 9 has ros2_control_node for hardware, but not for Gazebo.

I was assuming if I load say gz_ros2_control/GazeboSimSystem that it would work with ros2_control_node just the same way that fake_components/GenericSystem and robot_hardware_interface/RobotSystemHardware do, but it does not.

Basically, gz_ros2_control xml does not use any configuration for ros2_control_node yaml, they get configured differently, duplicating the same settings in different places, xml for Gazebo and yaml for ros2_control.

I would assume gz_ros2_control to be more a transparent bridge between the component configuration that doesn't change from simulation to hardware, reading and using the same settings, etc. I don't see a way to pass the yaml configuration into the XML plugin configuration for Gazebo, so you just duplicate those settings. I get, they could be different for simulation than hardware, but for consistency in simulation, they likely should be the same.

[christophfroehlich]

The diff-drive plugin you linked is not a ros2_controller but a gz plugin -> you can't use it on the hardware anyways.

All ros2_controller can be configured using the same yaml file for gz_ros2_control (loaded from the urdf) or by ros2_control_node (via ROS arguments), see example_9. You can even use the spawner script to load and configure them at runtime after the controller manager was loaded already. I don't see your point here.

[wltjr]

The diff-drive plugin you linked is not a ros2_controller but a gz plugin -> you can't use it on the hardware anyways.

Yes I know, but I have to have the Gazebo plugin with settings for the robot to move in Gazebo. It seems, I do not need the diff_drive_controller in my launch file, I thought in some trials I had to have that but just tried and could not confirm, so I will remove that.

If I remove/comment out libignition-gazebo-diff-drive-system.so plugin from my gazebo plugins, the robot does not move, and that is with passing the yaml file to the libgz_ros2_control-system.so plugin.

All ros2_controller can be configured using the same yaml file for gz_ros2_control (loaded from the urdf) or by ros2_control_node (via ROS arguments), see example_9. You can even use the spawner script to load and configure them at runtime after the controller manager was loaded already. I don't see your point here.

Example 9 does it how I am, loads yaml for hardware launch only, but for gazebo the yaml file passed in via the plugin as I am attempting to, but those settings are ignored or something. I should be able to use ros2_control_node with gazebo, but even example 9 excludes that from the launch file.

Basically, I should not have to load the diff drive plugin for gazebo, it should pick that up from ros2_control_node, load automatically, and diff_drive_controller settings passed to Gazebo without the need for the Gazebo plugin settings in XML. That would be how I would assume gz_ros2_control to work, from Gazebo to ros2 control, using the ros2 controller manger via its node. It may not need to load the diff drive plugin controller, but should read those settings and not require addition of diff drive plugin in xml for gazebo.

[christophfroehlich]

But gz_ros2_control (and gazebo_ros2_control) do not work with ros2_control_node for a good reason.

The gazebo diff drive system is something totally independent of ros2_control. But there is a diff_drive example within this repository. There it uses a yaml file, the same as which it could be used with your hardware.

[wltjr]

But gz_ros2_control (and gazebo_ros2_control) do not work with ros2_control_node for a good reason.

Sure, its just the yaml file is passed differently to each, and ros2_control_node can read it, but I get that gz_ros2_control is serving the same functionality, thus not using both.

The gazebo diff drive system is something totally independent of ros2_control. But there is a diff_drive example within this repository. There it uses a yaml file, the same as which it could be used with your hardware.

If you are referring to example 2, the diffbot, it only has a launch for rviz2 and not gazebo. Things did work differently with Gazebo Classic, but that was using gazebo_ros2_control. I did not have any xml settings for Gazebo Classic, I think it might have used the yaml file directly; I need to check commits before I removed support for Gazebo Classic.

[wltjr]

But there is a diff_drive example within this repository. There it uses a yaml file, the same as which it could be used with your hardware.

Found that example referenced, the one in the image in link, and it uses the same plugin via xml the diff_drive model.sdf file. That does not seem to use yaml at all, so this might be a functional difference or issue with gz_ros2_control vs gazebo_ros2_control, or more a difference in Gazebo (ign) and Gazebo Classic.

[christophfroehlich]

As far as I understand your comment, this issue can be closed.

[wltjr]

@christophfroehlich its not really resolved, but I can open a new issue as the main issue has been lost in the minutia of this one.

The main issue remaining seems to be gz_ros2_control not reading the yaml file for ros2_control, and including the diff-drive or other plugin automatically using the settings from the yaml file.

This file
https://github.com/wltjr/turbopi_ros/blob/main/config/turbopi_controllers.yaml

I should not have to do this
https://github.com/wltjr/turbopi_ros/blob/main/description/gazebo_plugins.xacro#L108

I need to test a bit more, but I am pretty sure anytime I remove that diff drive plugin from gazebo plugins it stops moving in gazebo, and also needs the settings duplicated in xml from yaml. I would like it to read the yaml file and load the necessary plugins, or something to that effect.

I will try to get time to look at the code myself and see if I can provide a PR or something along the lines of what I am seeking. But otherwise, this seems to have no impact
https://github.com/wltjr/turbopi_ros/blob/main/description/gazebo_plugins.xacro#L106

I believe I can remove that yaml portion of the main plugin config, and everything will work just the same, it does not seem to be reading or using that file at all.