Controller manager update_rate is wrongly limited by gazebo's simulation rate

[tonynajjar]

Describe the bug

The controller manager update_rate seems to be wrongly limited by gazebo's simulation rate

To Reproduce
Steps to reproduce the behavior:

I have a world with 60Hz update_rate and RTF 1.0 which is reached:

    <physics name="1ms" type="ode">
      <max_step_size>0.01666666</max_step_size>
      <real_time_factor>1.0</real_time_factor>
    </physics>

My controller_manager has an update_rate of 50 Hz:

/**:
  controller_manager:
    ros__parameters:
      update_rate: 50 # Hz

Expected behavior

I expect the controller manager to run at 50Hz, however the diagnostics complain that only 30Hz is reached.

If I change max_step_size to 0.01 (100Hz) then the CM is able to reach the 50Hz

Screenshots

Environment (please complete the following information):

• OS: Ubuntu Noble
• Version Jazzy

Additional context
Add any other context about the problem here, especially include any modifications to ros2_control that relate to this issue.

[christophfroehlich]

Isn't this an issue that your update rates don't have a common integer divider? The controller_manager update is only triggered with the update rate of gz

gz_ros2_control/gz_ros2_control/src/gz_ros2_control_plugin.cpp

Lines 514 to 526 in f9b4e7f

	// Get the simulation time and period
	rclcpp::Time sim_time_ros(std::chrono::duration_cast<std::chrono::nanoseconds>(
	_info.simTime).count(), RCL_ROS_TIME);
	rclcpp::Duration sim_period = sim_time_ros - this->dataPtr->last_update_sim_time_ros_;
	if (sim_period >= this->dataPtr->control_period_) {
	this->dataPtr->last_update_sim_time_ros_ = sim_time_ros;
	auto gz_controller_manager =
	std::dynamic_pointer_cast<gz_ros2_control::GazeboSimSystemInterface>(
	this->dataPtr->controller_manager_);
	this->dataPtr->controller_manager_->read(sim_time_ros, sim_period);
	this->dataPtr->controller_manager_->update(sim_time_ros, sim_period);
	}

[saikishor]

@tonynajjar I believe the max step should be a common divisor factor higher than the CM loop rate to be able to have proper simulation. For instance, a CM update rate of 100 Hz might need a step time of 0.005 or lower by the possible common factor. If not, you might observe some loop skipping.