0
$\begingroup$

I am reaching out to inquire about the limitations of the gz_ros2_control_plugin in accepting hardware components beyond the gz_ros2_control::GazeboSimSystemInterface.

I am currently developing a controller for the BlueROV2 vehicle, which relies on vehicle states, specifically body velocity as state interfaces and body efforts as command interfaces. I am utilizing the Blue project for testing purposes, which effectively provides a hardware component and a series of chained controllers that align with my controller requirements. However, the hardware component responsible for controlling the vehicle's thrusters communicates with the ardusub plugin, which emulates the actual BlueROV2 controller. In addition, this hw component is a child of the SystemInterface class.

The Blue project does not provide the vehicle body velocity as state interfaces; consequently, I have created a supplementary hardware component that subscribes to the topic provided by the Gazebo Odometry plugin through gz transport to supply the vehicle body velocities values in state interfaces. This newly developed hardware component, however, derives from the GazeboSimSystemInterface. Upon reviewing the gz_ros2_control_plugin code, I found that it currently only accommodates hardware components that inherit from GazeboSimSystemInterface, thereby preventing loading the ardusub hardware component in conjunction with my hardware component.

In light of this, I took the initiative to modify the gz_ros2_control_plugin locally to accept hardware components derived from the SystemInterface class. I implemented a new pluginlib loader and utilized the pluginlib API to redefine the parent class for that plugin, opting to bypass the initSim method when a plugin based on the SystemInterface is loaded. This small change works well.

Given this context, I would like to understand if there is a specific reason why the gz_ros2_control_plugin does not support other types of hardware components. If there is no substantial reason, I would be interested in proposing a pull request to incorporate this new feature. I am contacting this forum because I recognize that the maintainers may have valid concerns that I may not be aware of.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
0
$\begingroup$

It should be possible to write custom plugins of base class GazeboSimSystemInterface, I don't exactly understand your issue here.

But why do you want to launch ardusub with gazebo? It would be necessary to use an external ros2_control_node to load other hardware components: This is a recurring question, some design ideas can be found in this discussion why an external ros2_control_node does not work. But maybe there IS a workaround and we just haven't seen it yet?

Improve this answer
$\endgroup$
5
  • $\begingroup$ I know it is possible to create a custom plugin that inherits from the GazeboSystemInterface, and I have implemented this. My primary concern is that the GazeboSimROS2ControlPlugin is limited to loading hw components that derive explicitly from the GazeboSystemInterface. Thus, it will not load hw components derived from the SystemInterface, ActuatorInterface, or SensorInterface. I am working with a hw component derived from the SystemInterface that communicates with MavROS. Then, MavROS communicates with ´Ardupilot SITL. $\endgroup$ Commented Jun 1 at 17:52
  • $\begingroup$ To understand your usecase, why do you need this MavROS interface together with gazebo? $\endgroup$ Commented Jun 4 at 13:30
  • $\begingroup$ I'm running the blue simulation, which utilizes the ardupilot_gazebo to establish communication with the ArduPilot SITL. The objective is to evaluate a high-level controller. To summarize the transmission pathway of control signals from my controller to the simulated ROV, I have delineated the following sequence: my_high_level_controller → control_alloc_controller → thruster_controller → thruster_hardware → mavros → ardupilot_sitl → ardupilot_gazebo → gazebo_physics. $\endgroup$ Commented Jun 8 at 13:56
  • $\begingroup$ In this case I'd suggest to avoid using gz_ros2_control, and load your hardware plugin from a ros2_control_node with use_sim_time:=true, while you configure gazebo to publish the /clock topic, e.g, with the ros_gz_bridge $\endgroup$ Commented Jun 8 at 18:34
  • $\begingroup$ Okay, I will follow this approach. However, regarding my initial question, why does the GazeboSimROS2ControlPlugin not load hardware components derived from the SystemInterface, ActuatorInterface, and SensorInterface even being possible? $\endgroup$ Commented Jun 9 at 5:45

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.