Remove update loop filtering for publishing controller state

[jaron-l]

Background

Per the discussion in the working group meeting on Nov. 16th, all the controllers should not be filtering their update loops using a publisher period parameter. For example, the joint_trajectory_controller filers in the publish_state function using the associated parameter. Just remove the parameter and the check for it. Always publish the update when called.

Check the rest of the controllers and look for similar functionality to remove. It will always be in their update function or in a function called by the update function (like in the joint_trajectory_controller).

Instructions

Hi, this is a good-first-issue issue. This means we've worked to make it more legible to people who either haven't contributed to our codebase before, or even folks who haven't contributed to open source before.

We're interested in helping you take the first step, and can answer questions and help you out along the way. Note that we're especially interested in contributions from underrepresented groups!

We know that creating a pull request is the biggest barrier for new contributors. This issue is for you 💝

If you have contributed before, consider leaving this PR for someone new, and looking through our general bug issues. Thanks!

🤔 What you will need to know.

Nothing. This issue is meant to welcome you to Open Source :) We are happy to walk you through the process.

📋 Step by Step

• 🙋 Claim this issue: Comment below. If someone else has claimed it, ask if they've opened a pull request already and if they're stuck -- maybe you can help them solve a problem or move it along!

• 🗄️ Create a local workspace for making your changes and testing following these instructions, for Step3 use "Download Source Code" section with these instructions.

• 🍴 Fork the repository using the handy button at the top of the repository page and clone it into ~/ws_ros2_control/src/ros-controls/ros2_controllers, here is a guide that you can follow (You will have to remove or empty the existing ros2_controllers folder before cloning your own fork)

• Checkout a new branch using git checkout -b <branch_name>

• 🤖 Apply pre-commit auto formatting, by running pip3 install pre-commit and running pre-commit install in the ros2_control repo.

• 💾 Commit and Push your changes

• 🔀 Start a Pull Request to request to merge your code into master. There are two ways that you can start a pull request:

1. If you are not familiar with GitHub or how to create a pull request, here is a guide you can follow on how GitHub works.

• 🏁 Done Ask in comments for a review :)

Is someone else already working on this?

🔗- We encourage contributors to link to the original issue in their pull request so all users can easily see if someone's already started on it.

👥- If someone seems stuck, offer them some help!

🤔❓ Questions?

Don’t hesitate to ask questions or to get help if you feel like you are getting stuck. For example leave a comment below!
Furthermore, you find helpful resources here:

• ROS2 Control Contribution Guide
• ROS2 Tutorials
• ROS Answers

Good luck with your first issue!

[panxxhub]

now, like the 'joint_trajectory_controller', all the publish and trajectory sample/execution work are done at the update func ,which runs at a rt_thread, and shall we implement a new thread for the non-realtime staff?(a more complicate control node ,and a non-realtime scheduler, and add some func like update_nonrt in hardware_interface/controller_interface/resource_manager

[jaron-l]

now, like the 'joint_trajectory_controller', all the publish and trajectory sample/execution work are done at the update func ,which runs at a rt_thread, and shall we implement a new thread for the non-realtime staff?(a more complicate control node ,and a non-realtime scheduler, and add some func like update_nonrt in hardware_interface/controller_interface/resource_manager

I'm not sure I understand what you are asking. This won't require running a separate thread. This issue is just talking about removing one conditional branch from the update loop.

The update functions are not running on a RT thread, they run on non-realtime threads inside the executor that the controller was assigned to, just like most ROS2 nodes. The RT thread is run and handled by the realtime_tools package.

[tonynajjar]

Hi, could you explain the reason why we wouldn't want to publish some things at a different rate than the update() loop of the controller? I find it reasonable to want to publish some debugging state at a much lower frequency than the update() loop should run at. For example in the tricycle_controller, we publish the values sent to the hardware interface [here] purely for debugging purposes (

ros2_controllers/tricycle_controller/src/tricycle_controller.cpp

Line 249 in b72d0bb

realtime_ackermann_command_publisher_->unlockAndPublish();

); the publish rate of this publisher is currently not limited but I don't see a reason why it would not be.
Maybe there is some insight that was discussed in the WG that I'm missing?

[jaron-l]

Hi, could you explain the reason why we wouldn't want to publish some things at a different rate than the update() loop of the controller? I find it reasonable to want to publish some debugging state at a much lower frequency than the update() loop should run at. For example in the tricycle_controller, we publish the values sent to the hardware interface [here] purely for debugging purposes (

ros2_controllers/tricycle_controller/src/tricycle_controller.cpp

Line 249 in b72d0bb

realtime_ackermann_command_publisher_->unlockAndPublish();

); the publish rate of this publisher is currently not limited but I don't see a reason why it would not be.
Maybe there is some insight that was discussed in the WG that I'm missing?

This is issue is purely talking about removing a limit on the update loop itself. It is not affecting other things that are published.

[christophfroehlich]

The only occurrences I could find now are

• ros2_controllers/diff_drive_controller/src/diff_drive_controller_parameter.yaml

  Line 109 in 9063d8f

  publish_rate: {

• ros2_controllers/pose_broadcaster/src/pose_broadcaster_parameters.yaml

  Line 26 in 9063d8f

  publish_rate:

[Amronos]

From what I can tell the update loop of the diff_drive_controller is not limited by the publish_rate and only the publishing is limited:

ros2_controllers/diff_drive_controller/src/diff_drive_controller.cpp

Lines 203 to 219 in 9063d8f

	bool should_publish = false;
	try
	{
	if (previous_publish_timestamp_ + publish_period_ < time)
	{
	previous_publish_timestamp_ += publish_period_;
	should_publish = true;
	}
	}
	catch (const std::runtime_error &)
	{
	// Handle exceptions when the time source changes and initialize publish timestamp
	previous_publish_timestamp_ = time;
	should_publish = true;
	}
	if (should_publish)

It's the same for the pose_broadcaster:

ros2_controllers/pose_broadcaster/src/pose_broadcaster.cpp

Lines 173 to 188 in 9063d8f

	else if (realtime_tf_publisher_ && realtime_tf_publisher_->trylock())
	{
	bool do_publish = false;
	// rlcpp::Time comparisons throw if clock types are not the same
	if (tf_last_publish_time_.get_clock_type() != time.get_clock_type())
	{
	do_publish = true;
	}
	else if (!tf_publish_period_ || (tf_last_publish_time_ + *tf_publish_period_ <= time))
	{
	do_publish = true;
	}
	if (do_publish)
	{
	auto & tf_transform = realtime_tf_publisher_->msg_.transforms[0];

[christophfroehlich]

this was the same with the joint_trajectory_controller, but it was decided to remove this. I'd like to have the same pattern in every controller, but I can ask the senior @ros-controls/ros2-maintainers why this decision was made..

[christophfroehlich]

We discussed this in today's PMC meeting:

• It might make sense to have that parameter for controllers (but we don't readd it to JTC unless anyone asks for it)
• But it doesn't for broadcasters: Broadcasters purpose is to publish stuff, and one can simply set a different update rate of the controller.

@Amronos Do you want to take this and cleanup the pose_broadcaster?

[Amronos]

@Amronos Do you want to take this and cleanup the pose_broadcaster?

Sure!

[Amronos]

Should I deprecate the parameter and member variable(tf_publish_period_ and tf_last_publish_time_) or completely remove them?

[christophfroehlich]

Let's deprecate it for one release please, and then remove it on rolling after we branch off jazzy. No need to deprecate the member variable with compile time warnings, just mark the code sections with a comment and todo